{"action":"created","issue":{"url":"https://api.github.com/repos/m-labs/smoltcp/issues/160","repository_url":"https://api.github.com/repos/m-labs/smoltcp","labels_url":"https://api.github.com/repos/m-labs/smoltcp/issues/160/labels{/name}","comments_url":"https://api.github.com/repos/m-labs/smoltcp/issues/160/comments","events_url":"https://api.github.com/repos/m-labs/smoltcp/issues/160/events","html_url":"https://github.com/m-labs/smoltcp/issues/160","id":296141551,"number":160,"title":"Design: Implement IPv6 Extension Routing Header","user":{"login":"hjr3","id":33318,"avatar_url":"https://avatars1.githubusercontent.com/u/33318?v=4","gravatar_id":"","url":"https://api.github.com/users/hjr3","html_url":"https://github.com/hjr3","followers_url":"https://api.github.com/users/hjr3/followers","following_url":"https://api.github.com/users/hjr3/following{/other_user}","gists_url":"https://api.github.com/users/hjr3/gists{/gist_id}","starred_url":"https://api.github.com/users/hjr3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hjr3/subscriptions","organizations_url":"https://api.github.com/users/hjr3/orgs","repos_url":"https://api.github.com/users/hjr3/repos","events_url":"https://api.github.com/users/hjr3/events{/privacy}","received_events_url":"https://api.github.com/users/hjr3/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-02-10T22:51:38Z","updated_at":"2018-02-13T15:29:52Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"The Routing Header spec is at https://tools.ietf.org/html/rfc8200#section-4.4\r\n\r\nTwo questions about this:\r\n\r\n1. What routing types should we implement? IANA routing types are at https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-3.\r\n\r\n* Type 0 (aka Source Route) was defined in the original IPv6 RFC but has since been deprecated. Should we implement this route?\r\n* Type 1 (aka `Nimrod`) looks to be abandoned, so that is clear.\r\n* Type 2 is related to IPv6 Mobility https://tools.ietf.org/html/rfc6275#section-6.4. I think this type only makes sense to implement if we implement the rest of [RFC 6275](https://tools.ietf.org/html/rfc6275).\r\n* Type 3 (aka RPL Source Route) is defined in [RFC 6554](https://tools.ietf.org/html/rfc6554) and is the successor to Type 0.\r\n* There are two experiment types defined in [RFC 4727 - Section 3.6](https://tools.ietf.org/html/rfc4727#section-3.6). There is no definitive format specified for these, as they are meant to be used for experiments.\r\n\r\n2. How to represent the information for each routing type?\r\n\r\nThe [format](https://tools.ietf.org/html/rfc8200#section-4.4) of the routing type contains 4 common fields and an unspecified section for _type-specific data_ of variable length.\r\n\r\n* Should `Header#check_len` only ensure that there is enough data for the first 4 fields?\r\n* How should we deal with the different methods on each type? For example, there should be a `Header#home_address` method for a Type 3 header, but not one for a Type 2 header.\r\n* How should the `Repr` look? I can imagine something like:\r\n\r\n```rust\r\npub struct Repr {\r\n    pub next_header: Protocol,\r\n    pub header_len: u8,\r\n    pub routing_type: u8,\r\n    pub segments_left: u8,\r\n    pub type_spec_data: TypeSpecData,\r\n}\r\n\r\npub enum TypeSpecData {\r\n    Type2 { home_address: Ipv6Address },\r\n    Type3 { cmpr_i: u8, cmpr_e: u8, pad: u8 } // would need to add a vector of addresses too\r\n}\r\n```"},"comment":{"url":"https://api.github.com/repos/m-labs/smoltcp/issues/comments/365301429","html_url":"https://github.com/m-labs/smoltcp/issues/160#issuecomment-365301429","issue_url":"https://api.github.com/repos/m-labs/smoltcp/issues/160","id":365301429,"user":{"login":"hjr3","id":33318,"avatar_url":"https://avatars1.githubusercontent.com/u/33318?v=4","gravatar_id":"","url":"https://api.github.com/users/hjr3","html_url":"https://github.com/hjr3","followers_url":"https://api.github.com/users/hjr3/followers","following_url":"https://api.github.com/users/hjr3/following{/other_user}","gists_url":"https://api.github.com/users/hjr3/gists{/gist_id}","starred_url":"https://api.github.com/users/hjr3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hjr3/subscriptions","organizations_url":"https://api.github.com/users/hjr3/orgs","repos_url":"https://api.github.com/users/hjr3/repos","events_url":"https://api.github.com/users/hjr3/events{/privacy}","received_events_url":"https://api.github.com/users/hjr3/received_events","type":"User","site_admin":false},"created_at":"2018-02-13T15:29:52Z","updated_at":"2018-02-13T15:29:52Z","author_association":"CONTRIBUTOR","body":"I spoke to @dlrobertson and the goal is to allow parsing of the 4 common fields in the header and ignore the type specific data."}}
{"actor":{"display_login":"hjr3"}}