2013-02-07 19:35, Roger Jørgensen <[email protected]> : > sorry, but we can't all be nice all the time, see more inline, > > > On Thu, Feb 7, 2013 at 7:21 PM, Rémi Després <[email protected]> wrote: > <snip> >> (b) The benefit comes from the following, i.e. one of the 4rd objectives: >> - We want to statelessly establish automatic tunnels for residual IPv4 >> across IPv6-only domains. > > not a bad idea, but don't we have other options in this area?
In Softwire, conclusion has been this was a tool to have. >> - We don't want, when doing so, to impose any renumbering of IPv6 link >> and/or host. > > excellent, any protocol/idea that impose this is quite badly designed. (*) Good. >> - This is possible ONLY IF we use, for each CE tunnel endpoint, an IPv6 >> address that no host in the CE site may be using. > > I have always thought any address I get on my host from dhcpv6/ra or > similar, mixed with DAD and other mechanism are as close to a guaranty > as we can get. Hosts of an IPv6 customer site can have IPv6 addresses assigned, with SLAAC or DHCPv6, BEFORE 4rd is activated. If these addresses become in conflict with the CE 4rd address when 4rd is activated, renumbering becomes necessary. The objective (*) isn't satisfied. (Reason why the CE itself cannot take another address is because this address must be *algorithmically derived* from an a IPv4 destination by other CEs.) > No need for some magic bits of any type. Bits u and g haven't been invented for 4rd. Using u=1 for future technologies, is anticipated in RFC4291 itself. No magic involved. >> - Fortunately this happens to be feasible, with IPv6 as is: in a site that >> is delegated a prefix up to /64, no host that has a global unicast address >> conforming to RFC4291 may have an IID in which u=g=1. > > ... You just ASSUME something I think we all understand is not > possible to guaranty. There will be collision, deal with it. Let me make the point again. It is a fact (not an assumption) that RFC4291-conforming IIDs either have u=0, in which case other bits may have any values, or, if they have have g=1, have a specified structure. So far the only such structure is that of IEEE derived IIDs. With it, g=0 because these IIDs are those of unicast addresses. If, in your understanding, RFC 4291 authorizes IIDs having u=g=1, PLEASE EXPLAIN. > Someone will probably sooner than later, assign either auto (yes they > break the "rule") Auto assignments that break the rules are bound to create problems anyway. Their bugs need to be fixed. > or manual an address that will cause two hosts on > the same link/site to have the same address no matter how much you > ASSUME the above (u=g=1...) Manual mistakes do occur, yes. They have to be fixed like other bugs. >> - By reserving a small subset of this unused IID space, we reach our >> objective. >> >> Hope it clarifies. > > yes it clarifies to me that you suggest a quite broken way of using > IPv6 addresses. You ASSUME things, among that some magic bits (u and > g) will give you something close to an unique address. I hope you will eventually understand that so much negativeness isn't justified. Fortunately for me, a number of highly experienced 6man contributors have already expressed their view that the proposed range reservation isn't a problem. Regards, RD > > > > -- > > Roger Jorgensen | ROJO9-RIPE > [email protected] | - IPv6 is The Key! > http://www.jorgensen.no | [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
