Rémi Després wrote: > 2013-01-30 16:59, Ray Hunter <v6...@globis.net> : > ... >> my 2 cents. >> >> If 4rd is truly experimental then indeed I think it's up to the >> operators deploying it to ensure they choose a unique IID range within >> the scope of where they are operating 4rd (between tunnel endpoints and >> the tunnel gateway). > > This misses the point that 4rd IIDs are chosen to be collision-free with all > possible IPv6 hosts that, in sites that use 4rd for IPv4, are configured with > SLAAC (and therefore have to comply with RFC4291). > IIDs of these hosts are assigned independently of any knowledge that 4rd is > used or not. Understood. No new reservation is required. No new behaviour is required of existing hosts. >> My initial concerns were that this could cause harm >> even in experimental form, but I've convinced myself that it shouldn't. >> In this case I see no need for a hard global IID reservation, because at >> the moment, u=g=1 isn't used for creating IID's for use with SLAAC. >> >> On the other hand, If 4rd is not truly experimental, or it's expected to >> work universally across AS boundaries, I suspect the WG will have to >> wait for an answer to Brian's question on whether structure within the >> IID is desirable. I don't think there's any clear consensus so far on >> that point > >> (indeed there are some counter posts saying structure within >> the IID is undesirable). > > OK, it is a fact that, *for some addresses that aren't concerned with SLAAC*, > typically some manually configured addresses, the IID structure of RFC 4291 > can be ignored. One example where it is actually ignored is in RFC 6164 > which deals with /127 prefixes on inter-router links. (Incidentally, I have > been an active supporter of this RFC, as Miya Kohno may remember. Understood. People running 4rd have to ensure manually assigned addresses avoid the 4rd range. Making a global reservation or not will likely not significantly change the impact of that. > But it is ALSO A FACT that *for IIDs that are used in SLAAC* there is some > IID structure, the so called Modified EUI-64 format. (If u= other bits have > no structure; if u=1, other bits must be based on IEEE link addresses. They > then always have g=0, other combinations remaining available for future > technologies.) > This structure is effectively used in OSes to automatically provide, by > default, addresses that are stable in their environment. If MUST NOT be > abandoned for addresses subject to SLAAC. Understood. No new reservation is required. No new behaviour is required of existing hosts. >> My own particular concern here is that there is a danger of creating a >> precedent of a completely new class of IPv6 addressing by the back door >> without this being fully and properly debated i.e. address ranges that >> don't perform DAD, and that are associated directly with a certain >> tunnel or transport protocol, and yet which are assigned within the >> generic GUA space, but perhaps which overlap with other IPv6 prefix >> spaces too. >> >> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by >> 6to4 (2002::/16) being associated with 4rd IIDs? > > 6to4 IIDs are ordinary unicast-address IIDs, subject to RFC 4291. > Consistency of the 4rd IID range with RFC 4291 therefore avoids any risk of > conflict with 6to4. Right, so you're saying it's perfectly valid to combine a 64 bit 6to4 prefix with a 64 bit 4rd IID?
Won't anything that currently assumes 6to4 has exclusive use of 2002::/16 potentially have a problem, because actually the traffic isn't really 6to4? >> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport >> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08 >> (both of which assume that bit-contiguous left-anchored IPv6 prefixes >> map to transport protocols, not individual IID bits)? > > 4rd addresses are those of tunnel endpoints in BRs and CEs. They are > therefore not concerned with Address selection policies that are needed for > applications having to choose among several source and/or destinations. > So a CE router never sources or terminates an IPv4 or IPv6 session? So a 4rd tunnel will never terminate on an end user device? What about mobile phones and tablets attached to IPv6 only networks? Wouldn't it be very attractive (and therefore likely) for them to act as their own 4rd tunnel endpoint? > >> These questions probably have little relevance to 4rd being deployed in >> an experimental situation, and I think we should perhaps try to keep >> them decoupled as far as possible. > > Reservation of an unused IID range among those of RFC4291 is in my > understanding already decoupled from the above issues. This reservation would > be as safe if 4rd would be on standard track instead of experimental. > > Regards, > RD > > > >>> one of my concerns is that continuing to add the interface-id bits, is the >>> opposite direction of where >>> I want us to go. >>> >>> I wouldn't object to non-normative language in 4rd suggesting a >>> interface-id to use, without >>> creating any expectation that new or existing IPv6 implementations have to >>> change. >>> >>> that said, 4rd will work perfectly well _without_ this reservation, so I >>> don't buy the argument that >>> we're holding up the 4rd work. >>> >>> cheers, >>> Ole >>> >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
