Re: IIDs, u and g bits, and 4rd

2012-12-23 09:14, Brian E Carpenter : > Ray, > > That is about an IEEE EUI-48 and we are talking about an IETF Modified EUI-64. True, but the same RFC 5342 says, in its EUI-64 section, "As with EUI-48 identifiers, the OUI has the same Group/unicast and Local/Global bits." > I think we can

Re: IIDs, u and g bits, and 4rd

Ray, That is about an IEEE EUI-48 and we are talking about an IETF Modified EUI-64. I think we can say whatever we like about the bits in an IETF Modified EUI-64. Brian On 22/12/2012 20:48, v6...@globis.net wrote: > After some searching, I've finally found a reference in an IETF BCP > docume

Re: IIDs, u and g bits, and 4rd

After some searching, I've finally found a reference in an IETF BCP document that to my mind does demonstrate that u==1 && g==1 && unicast IID = "currently unused" http://tools.ietf.org/html/rfc5342 Quote: "Two bits within the initial 3 octets of an EUI-48 have special significance: the G

Re: IIDs, u and g bits, and 4rd

On 12/19/2012 07:37 AM, Ole Troan wrote: > [...] > >> I briefly read into the 4rd draft, but it's not entirely clear to me >> whether other solutions don't exist. Maybe there are other means to >> get the context knowledge that this particular IPv6 address has a >> special structure encoded someho

Re: IIDs, u and g bits, and 4rd

2012-12-20 à 16:50, "Bless, Roland (TM)" : > Hi Rémi, > > On 20.12.2012 09:54, Rémi Després wrote: >> Interface addresses at the link layer are specified by IEEE to be >> universally unique. This has been effective fort link-layer >> communication to need neither manual configuration nor a DAD

Re: IIDs, u and g bits, and 4rd

2012-12-21 12:00, Ole Troan : > Remi, > >>> there appears to be quite a lot of pushback in 6man against the use of u/g >>> bits as specified in the 4rd draft. >> >> FUD, yes, but technically founded pushback that haven't been answered, no >> one left AFAIK. > > I can't parse the above. Fa

Re: IIDs, u and g bits, and 4rd

Ray, Please see inline. 2012-12-21 à 14:03, Ray Hunter : ... >> The basic question is whether reserving for 4rd a specific 8-bit IID is >> "compatible with the IPv6 addressing architecture" as currently specified. >> Besides some expressed FUD, which isn't illegitimate in face of anything >> ne

Re: Re: IIDs, u and g bits, and 4rd

Inline Rémi Després wrote: > 2012-12-20 20:29, Ole Troan : > >> Remi, >> >> [...] >> To make assertions about IP addresses based on the EUI-64 is to impose requirements that don't actually exist in IP. It's a little like saying that concrete MUST ("are required to") be grey becau

Re: IIDs, u and g bits, and 4rd

Remi, >> there appears to be quite a lot of pushback in 6man against the use of u/g >> bits as specified in the 4rd draft. > > FUD, yes, but technically founded pushback that haven't been answered, no one > left AFAIK. I can't parse the above. > For instance, in you own long list of doubts,

Re: IIDs, u and g bits, and 4rd

Le 2012-12-21 à 10:37, Ole Troan a écrit : ... This isn't a reason, however, to abandon rules that proved to be useful. AFAIK, the rule that IIDs having u=1 must (so far) only be based on global IEEE EUI-64 addresses is one of these useful rule not to be abandoned. >>> >>> how

Re: IIDs, u and g bits, and 4rd

Remi, To make assertions about IP addresses based on the EUI-64 is to impose requirements that don't actually exist in IP. It's a little like saying that concrete MUST ("are required to") be grey because the rocks we use in it happen to be grey; no I can have concrete of oth

Re: IIDs, u and g bits, and 4rd

Jouni, At this point, it appears that just adding one IID range reservation to those of RFC5453 (to be registered by IANA), can do the job. No need to change any existing RFC. Besides, as suggested by Brian, a different IID range than that of the current 4rd draft can be recommended by 6man.

Re: IIDs, u and g bits, and 4rd

2012-12-20 20:29, Ole Troan : > Remi, > > [...] > >>> To make assertions about IP addresses based on the EUI-64 is to impose >>> requirements that don't actually exist in IP. It's a little like saying >>> that concrete MUST ("are required to") be grey because the rocks we use in >>> it happ

Re: IIDs, u and g bits, and 4rd

On Dec 20, 2012, at 3:02 PM, Randy Bush wrote: >>> "The IID consists of N bits that have no meaning; the only constraint >> >> Hmm.. how would this work with RFC5453 reserved IID space we already >> have for anycast addresses? > > is anyone aware of any deployment of the ipv6 invented any cast

Re: IIDs, u and g bits, and 4rd

2012-12-20 19:34, "Fred Baker (fred)" : > > On Dec 20, 2012, at 9:35 AM, Rémi Després wrote: >>> The comment Brian is making refers to IP's requirements, which are that the >>> IID used in a subnet by an interface must be unique within that subnet. >> >> This is a clear requirement, on which

Re: IIDs, u and g bits, and 4rd

- Original Message - > From: Bob Hinden > To: Randy Bush > Cc: "ipv6@ietf.org List" ; Bob Hinden > Sent: Friday, 21 December 2012 1:47 AM > Subject: Re: IIDs, u and g bits, and 4rd > > Randy, > > On Dec 20, 2012, at 3:02 PM, Randy Bush wrote:

Re: IIDs, u and g bits, and 4rd

Remi, [...] >> To make assertions about IP addresses based on the EUI-64 is to impose >> requirements that don't actually exist in IP. It's a little like saying that >> concrete MUST ("are required to") be grey because the rocks we use in it >> happen to be grey; no I can have concrete of othe

Re: IIDs, u and g bits, and 4rd

On Dec 20, 2012, at 9:35 AM, Rémi Després wrote: >> The comment Brian is making refers to IP's requirements, which are that the >> IID used in a subnet by an interface must be unique within that subnet. > > This is a clear requirement, on which I think we all agree. > > It is worth noting here

Re: IIDs, u and g bits, and 4rd

Fred, Please see inline. 2012-12-20 à 17:32, "Fred Baker (fred)" : > > On Dec 20, 2012, at 12:54 AM, Rémi Després wrote: > >> Interface addresses at the link layer are specified by IEEE to be >> universally unique. > > Yes, and EIU-64 is one of several seeds from which an IID can be derived

Re: IIDs, u and g bits, and 4rd

On Dec 20, 2012, at 12:54 AM, Rémi Després wrote: > Interface addresses at the link layer are specified by IEEE to be universally > unique. Yes, and EIU-64 is one of several seeds from which an IID can be derived. It's not the only one. The fact that an underlying technology provides an inte

Re: IIDs, u and g bits, and 4rd

Hi Rémi, On 20.12.2012 09:54, Rémi Després wrote: > Interface addresses at the link layer are specified by IEEE to be > universally unique. This has been effective fort link-layer > communication to need neither manual configuration nor a DAD-like > protocol at this layer. IEEE link layer address

Re: IIDs, u and g bits, and 4rd

Le 20/12/2012 14:02, Randy Bush a écrit : "The IID consists of N bits that have no meaning; the only constraint Hmm.. how would this work with RFC5453 reserved IID space we already have for anycast addresses? is anyone aware of any deployment of the ipv6 invented anycast? In Mobile IPv6 the

Re: IIDs, u and g bits, and 4rd

Randy, On Dec 20, 2012, at 3:02 PM, Randy Bush wrote: >>> "The IID consists of N bits that have no meaning; the only constraint >> >> Hmm.. how would this work with RFC5453 reserved IID space we already >> have for anycast addresses? > > is anyone aware of any deployment of the ipv6 invented an

Re: IIDs, u and g bits, and 4rd

>> "The IID consists of N bits that have no meaning; the only constraint > > Hmm.. how would this work with RFC5453 reserved IID space we already > have for anycast addresses? is anyone aware of any deployment of the ipv6 invented anycast? like most ipv6 magic, i think it is ignored and regular

Re: IIDs, u and g bits, and 4rd

2012-12-19 21:27, "Bless, Roland (TM)" : > Hi Rémi, > > On 19.12.2012 18:59, Rémi Després wrote: > >> As is, the sentence misses that IIDs that have u=1 are expected to be >> universally unique. (This uniqueness is key to ensure that, as long > > I don't agree. From an IPv6 functional point o

Re: IIDs, u and g bits, and 4rd

On Dec 19, 2012, at 5:58 PM, Brian E Carpenter wrote: > On 19/12/2012 14:44, Bless, Roland (TM) wrote: >> Hi, >> >> On 19.12.2012 14:21, Rémi Després wrote: >>> Could we limit the 6man discussion to the question asked by Softwire, >>> i.e. whether new IID types can be defined, using u=g=1, wit

Re: IIDs, u and g bits, and 4rd

2012-12-19 23:01, Roger Jørgensen : ... > if you read RFC4291 and section 2.5.1. you'll see the following two paragraphs > > IPv6 nodes are not required to validate that interface identifiers > created with modified EUI-64 tokens with the "u" bit set to universal > are unique. That's prec

Re: IIDs, u and g bits, and 4rd

> > It seems to me with the benefit of hindsight that a fundamentally better > > approach would have been to reserve many more bits in the IID, or in RA > > PIO, to create mutually exclusive subspaces per assignment mechanism or > > per class of assignment mechanism, but that train has probably lef

Re: IIDs, u and g bits, and 4rd

Jouni, On 19/12/2012 21:19, Jouni Korhonen wrote: > On Dec 19, 2012, at 5:58 PM, Brian E Carpenter > wrote: > >> On 19/12/2012 14:44, Bless, Roland (TM) wrote: >>> Hi, >>> >>> On 19.12.2012 14:21, Rémi Després wrote: Could we limit the 6man discussion to the question asked by Softwire, >>

Re: Re: IIDs, u and g bits, and 4rd

see inline: On Wed, Dec 19, 2012 at 9:57 AM, Ray Hunter wrote: > OK I'll bite. All IMVHO. > > In answer to Fred's question, to me the current problem is on the end > hosts and not on existing intermediate devices. > > There are many different ways to assign IPv6 addresses, including manual > ass

Re: IIDs, u and g bits, and 4rd

On Wed, Dec 19, 2012 at 2:21 PM, Rémi Després wrote: > Ole, Roland, > > Could we limit the 6man discussion to the question asked by Softwire, i.e. > whether new IID types can be defined, using u=g=1, with a first one for 4rd, > is compatible with the current IPv6 specification? sorry, but you

Re: IIDs, u and g bits, and 4rd

> > From: "Bless, Roland (TM)" >To: Rémi Després >Cc: ipv6@ietf.org >Sent: Thursday, 20 December 2012 7:27 AM >Subject: Re: IIDs, u and g bits, and 4rd > >Hi Rémi, > >On 19.12.2012 18:59, Rémi Després wrote: > &

Re: IIDs, u and g bits, and 4rd

Hi Rémi, On 19.12.2012 18:59, Rémi Després wrote: > As is, the sentence misses that IIDs that have u=1 are expected to be > universally unique. (This uniqueness is key to ensure that, as long I don't agree. From an IPv6 functional point of view, IIDs only need to be unique within the link-local/

Re: IIDs, u and g bits, and 4rd

On 19.12.2012 16:58, Brian E Carpenter wrote: >> Do we really have such a thing "IID types"? > > I think that's an important point. If we could make a statement like > > "The IID consists of N bits that have no meaning; the only constraint > is that they must be unique within the scope of a given

Re: IIDs, u and g bits, and 4rd)

Le 19/12/2012 00:50, Joel M. Halpern a écrit : In reading the discussion,a nd trying to think through what I understand to be correct, it seems that there is an unforeseen ambiguity in the way the current documents about IPv6 IIDs are written. I think that there are two possible meanings, ad we

Re: IIDs, u and g bits, and 4rd

2012-12-19 16:58, Brian E Carpenter : > On 19/12/2012 14:44, Bless, Roland (TM) wrote: >> Hi, >> >> On 19.12.2012 14:21, Rémi Després wrote: >>> Could we limit the 6man discussion to the question asked by Softwire, >>> i.e. whether new IID types can be defined, using u=g=1, with a first >>

Re: IIDs, u and g bits, and 4rd

On 19/12/2012 14:44, Bless, Roland (TM) wrote: > Hi, > > On 19.12.2012 14:21, Rémi Després wrote: >> Could we limit the 6man discussion to the question asked by Softwire, >> i.e. whether new IID types can be defined, using u=g=1, with a first > > Sorry, I'm not yet awa

Re: IIDs, u and g bits, and 4rd

On Dec 19, 2012, at 1:24 AM, Rémi Després wrote: > (c) In the Identifier-Locator Network Protocol of RFC 6741 (ILNP), the IEEE > semantic of g=0 applies to unicast addresses (section 3). Besides, "ILNP uses > IPv6 multicast for ILNPv6", which implies that addresses are not concerned > with IID

Re: IIDs, u and g bits, and 4rd

Hi, On 19.12.2012 14:21, Rémi Després wrote: > Could we limit the 6man discussion to the question asked by Softwire, > i.e. whether new IID types can be defined, using u=g=1, with a first Sorry, I'm not yet aware of a concept called IID _types_? Do we really have such

Re: IIDs, u and g bits, and 4rd

Fred, > u and g are a recurring theme. Apart from the people who wrote RFC 4291, who > are under the delusion that the only link layer in the world is an Ethernet, > who actually cares? I am one of the authors of RFC4291. I am not under any delusion that Ethernet is the only link layer. I ha

Re: IIDs, u and g bits, and 4rd

>> What, on an IPv6 host or router, cares about the g bit apart from the >> code that uses an EUI-48 or EUI-64 to create an EID? What starts from >> an EID and extracts from it an EUI-64/48 address, or in any other way >> interprets the g flag in an EID? >> >> u and g are a recurring theme. Apart

Re: IIDs, u and g bits, and 4rd

> What, on an IPv6 host or router, cares about the g bit apart from the > code that uses an EUI-48 or EUI-64 to create an EID? What starts from > an EID and extracts from it an EUI-64/48 address, or in any other way > interprets the g flag in an EID? > > u and g are a recurring theme. Apart from t

Re: IIDs, u and g bits, and 4rd

Ole, Roland, Could we limit the 6man discussion to the question asked by Softwire, i.e. whether new IID types can be defined, using u=g=1, with a first one for 4rd, is compatible with the current IPv6 specification? If the answer is positive (as it seems it can be), restarting a discussion on

Re: IIDs, u and g bits, and 4rd

Hi Ole, Thanks for clarification. See below for comments. On 19.12.2012 13:37, Ole Troan wrote: > the interface-ids that 4rd uses must be unique on the link, and it doesn't > handle conflicts with other (native) nodes well. > alternative approaches to reserving interface-id space for this mechan

Re: IIDs, u and g bits, and 4rd

Le 2012-12-19 à 11:20, Ray Hunter a écrit : >> Rémi Després >> 19 December 2012 10:45 >> Hello, Ray, >> >> 2012-12-19 09:57, Ray Hunter : >> ... >> >> The proposal is precisely to use the only remaining unused pattern >> (u=g=1) as an escape mechanism FOR ALL

Re: IIDs, u and g bits, and 4rd

[...] > I briefly read into the 4rd draft, but it's not entirely clear to me > whether other solutions don't exist. Maybe there are other means to > get the context knowledge that this particular IPv6 address has a > special structure encoded somehow. as a clarification of what has happened in so

Re: IIDs, u and g bits, and 4rd

Hi, it's not really clear to me what (particular) problem we are trying to solve here. I don't think that it's a good idea to introduce a structure into the IID. The IID space is usually flat and the u- and g-bit semantics are only relevant in the IEEE EUI format. It's clear that we map them someh

Re: IIDs, u and g bits, and 4rd

> Rémi Després > 19 December 2012 10:45 > Hello, Ray, > > 2012-12-19 09:57, Ray Hunter : > ... > > The proposal is precisely to use the only remaining unused pattern > (u=g=1) as an escape mechanism FOR ALL future IID formats. > (Among IIDs having u=g=1, 4rd is pr

Re: IIDs, u and g bits, and 4rd

Hello, Ray, 2012-12-19 09:57, Ray Hunter : ... > It seems to me with the benefit of hindsight that a fundamentally better > approach would have been to reserve many more bits in the IID, or in RA > PIO, to create mutually exclusive subspaces per assignment mechanism or > per class of assignment m

Re: IIDs, u and g bits, and 4rd

Hello, Fred, 2012-12-19 01:35, Fred Baker (fred) : > Why do we care about u and g in the first place? Is there code in an IPv6 > router or host that interprets them? The current situation is AFAIK the following: (a) No RFC implies behaviors that differ depending on whether g=0 or g=1 in recei

Re: Re: IIDs, u and g bits, and 4rd

OK I'll bite. All IMVHO. In answer to Fred's question, to me the current problem is on the end hosts and not on existing intermediate devices. There are many different ways to assign IPv6 addresses, including manual assignment, that can all run simultaneously on the same interface/link and the sa

Re: IIDs, u and g bits, and 4rd

On 19/12/2012 01:16, Joel M. Halpern wrote: > Phrased that way, I do not think any stack anywhere looks at the U or G > its in a received IPv6 address. That's why I asked if ILNP depends on the u bit. You presumably saw Ran's reply, including "The U bit does have value for ILNP." > I have no prob

Re: IIDs, u and g bits, and 4rd

Phrased that way, I do not think any stack anywhere looks at the U or G its in a received IPv6 address. I have no problem if we declare hem to be irrelevant. Your, Joel On 12/18/2012 8:13 PM, Fred Baker (fred) wrote: As you know, the EUI-64 address is but one of the seeds that an EID can be

Re: IIDs, u and g bits, and 4rd

As you know, the EUI-64 address is but one of the seeds that an EID can be generated from. Having been generated, it's a bit string, and another bit string either equals it or doesn't. You didn't answer my question. What, on an IPv6 host or router, cares about the g bit apart from the code that

Re: IIDs, u and g bits, and 4rd

As I understand it, the original intent with the U bit was to provide an easy way to create IID that were highly likely to be distinct from all other IIDs (on the link). As IEEE reserves the G bit, we marked that as special as well when the U bit was set. Changing the meaning of U=1, G=0 seem

Re: IIDs, u and g bits, and 4rd

Why do we care about u and g in the first place? Is there code in an IPv6 router or host that interprets them? On Dec 18, 2012, at 3:50 PM, Joel M. Halpern wrote: > In reading the discussion,a nd trying to think through what I understand to > be correct, it seems that there is an unforeseen amb