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: > >> As is, the sentence misses that IIDs that ha

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: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments

Hi Fernando, > -Original Message- > From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Tuesday, December 18, 2012 12:00 PM > To: Templin, Fred L > Cc: draft-ietf-6man-ipv6-atomic-fragme...@tools.ietf.org; 6man WG > Subject: Re: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments >

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: Review requested: draft-ietf-mif-dhcpv6-route-option

Hi Wes, On Oct 28, 2011, at 1:52 PM, Wes Beebee wrote: > What happens when both RA and DHCPv6 are configured? Both sets of routes are configured. This is exactly analogous to a situation where RAs are used and an administrator has configured some routes using a configuration tool like "rout

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