Washam, thanks for all your comments!
> Techincal comments: > > 1. 6rd BR definition in section 3 says: > > 6rd Border Relay (BR) A 6rd-enabled router managed by the service > provider at the edge of a 6rd domain. The 6rd > BR router has at least one of each of the > following: an IPv4-enabled interface, a 6rd > virtual interface acting as an endpoint for the > 6rd IPv6 in IPv4 tunnel, and an IPv6 interface > ^^^^^^^^^^^ > connected to the native IPv6 network. A 6rd BR > ^^^^^^^^^^^^^^^^^^^^^^^^ > may also be referred to simply as a "BR" within > the context of 6rd. > > 6rd BRs might not be deployed in IPv4/IPv6 border or 6rd BRs > might use virtual interface (v.s. physical interface) to connect to > a IPv6 overlay (v.s. native IPv6). > > The same situation applies to 6rd CEs, e.g., a 6rd CE might be > an ISATAP router. indeed. but I don't think we need to say anything about that in the draft. > 2. section 4 talks about 6rd delegated prefix delegation rather > than 6rd prefix delegation. Should the title be changed? the mechanism is called "prefix delegation", while the resulting prefix is called a "delegated prefix". hopefully that doesn't create too much confusion. > 3. section 6 says 6rd addresses should be treated as native > addresses and no changes are needed for address selection. > > 6rd is a native-equivalent IPv6, but not native IPv6 after all. > When a customer is connected to a 6rd IPv6 and native IPv6 > at the same time, (s)he might only want to use 6rd address > when (s)he communicates with hosts within the 6rd domain. I concur with Brian here. > 4. the 6rdPrefixLen semantics in section 7.1.1 says: > > 6rdPrefixLen The IPv6 Prefix length of the SP's 6rd IPv6 > prefix in number of bits. For the purpose > of bounds checking by DHCP option > processing, the sum of (32 - IPv4PrefixLen) > + 6rdPrefixLen MUST be less than or equal > ^^^^^^^^^^^^^^^^^^ > to 128. The 6rd implementation may further > ^^^^ > limit the sum of these lengths to 64. > > But the last sentences in para2, sec4 says > > To allow for stateless address auto-configuration on > the CE LAN Side, a 6rd delegated prefix MUST be /64 or shorter. > > the sum of (32-IPv4PrefixLen)+6rdPrefixLen = size of the > 6rd delegated prefix. Is it an inconsistency? just maintaining the ambiguity we have with IPv6 today. ;-) should the 64 bit boundary be enforced in the DHCP option bounds checking? I see no technical reason why the DHCP option shouldn't allow for any prefix length. at the same time we want to point out that unless it is at least a /64 then SLAAC will not work. > 5. at the end of the section 7.2, the RIB appears as: > > ::/0 -> 2001:ABC0:0000:0100:: (default route) > 2001:ABC0::/32 -> 6rd-virtual-interface0 (direct connect to 6rd) > 2001:ABC0:6464:0100::/56 -> Null0 (delegated prefix sink route) > 2001:ABC0:6464:0100::/64 -> Ethernet0 (LAN interface) > > The routes are confusing. The first route indicates the next > hop whileas the rest routes indicate the coresponding interface. > Actually, the first route should have indicated 6rd-virtual-interface0 > but with the specific next hop 2001:ABC0:0000:0100:: agree, I've added that to the RIB example: ::/0 -> 6rd-virtual-interface0 via 2001:ABC0:0000:0100:: (default route) 2001:ABC0::/32 -> 6rd-virtual-interface0 (direct connect to 6rd) 2001:ABC0:6464:0100::/56 -> Null0 (delegated prefix sink route) 2001:ABC0:6464:0100::/64 -> Ethernet0 (LAN interface) > 6. In section 8, you give one recommended method for NUD > between CEs and BRs, so what is recommended for NUD > between CEs and BRs? I'm not quite sure what you mean here? > 7. It is still hard for me to get to looping issues described in > section 12, it would help if an example was there. yes, me too. ;-) check out: http://www.townsley.net/ietf76/townsley-ietf76-softwires-6rd-update.pdf and Nakibly and Arov's [USENIX09 ] Nakibly, G. and M. Arov, "Routing Loop Attacks using IPv6 Tunnels, USENIX WOOT", August 2009. I'll add an informative reference to this paper. > 8. compared to 6to4 spec (rfc3056), this document does not > mention the routing exchange between CEs and BRs, especially > when anycast is not used for BR discovery. Is this the original > intention? yes. we are considering the same deployment scenario as e.g draft-ietf-v6ops-ipv6-cpe-router and there is no dynamic routing between a CPE and a service provider's edge. > editorial comments: > > 9. the first sencence in para4, sec1: > > A 6rd domain consists of 6rd Customer Edge (CE) routers and one or > more 6rd BRs. > ^^^^^ > I prefer "6rd Border Relay (BR) routers" instead. agree, fixed. > 10. CE IPv4 address definition in sec3: > > CE IPv4 address The IPv4 address given to the CE as part of > normal IPv4 Internet access (i.e., configured > via DHCP, PPP, or otherwise). This address may > be global or private [RFC1918] within the 6rd > domain. This address is used by a 6rd CE to > create the 6rd delegated prefix as well as to > send and receive IPv4 encapsulated IPv6 > ^^^^^^^^^^^^^^ > packets. > > Should it be IPv6 encapsulated IPv4? absolutely, fixed. > 11. 1st sentence in sec4: > > The 6rd delegated prefix for use at a customer site is created by > combining the 6rd prefix and some or all of the CE IPv4 Address. > > ^^^^^^ > addresses. actually it is singular. changed "some" to "part of". this is the case where part of the IPv4 prefix can be pre-configured on all 6rd nodes and therefore you don't need to encode the complete 32 bit IPv4 address in the IPv6 address. > 12. the para2, sec4: > > In 6to4, a similar operation is performed by incorporating an entire > IPv4 address at a fixed location within a well-known /16 IPv6 prefix. > ^^^^ following fixed. > In 6rd, the IPv6 prefix as well as the position and number of bits of > the IPv4 address incorporated varies from one 6rd domain to the next. > 6rd allows the SP to adjust the size of the 6rd prefix, bits used by > > ^how many fixed. > the 6rd mechanism, and how many bits are left to be delegated to > customer sites. To allow for stateless address auto-configuration on > the CE LAN Side, a 6rd delegated prefix MUST be /64 or shorter. > > 13. IID is not in right propositional to the address length in figure 1. fixed. > 14. last para, sec5: > > The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast > address [RFC4291] for its own 6rd delegated prefix. This allows, for > example, IPv6 ping messages to be sent to the 6rd Virtual Interface > itself for additional troubleshooting of the internal operation of > 6rd at a given CE or BR, over and above an IPv4 ping to the > ^^^^^^^^^^^^^^^^^^^ ( I don't get it) > associated CE or BR IPv4 address. In the case of the BR, the IPv4 > address used to calculate the 6rd delegated prefix is the configured > BR IPv4 Address. we just tried to say that with a well known IPv6 address to ping (subnet router anycast) then that can be used for troubleshooting. in addition to using the IPv4 address. happy to edit if you have a suggestion of better text. > 15. para2, sec9: > > IPv6 packets from a CE are encapsulated in IPv4 packets when they > leave the site via its CE WAN Side interface. The CE IPv4 address > ^^^ A > MUST be configured to send and receive packets on this interface. "A"? thanks again for very thorough comments! cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
