2013-02-01 21:57, RJ Atkinson rja.li...@gmail.com :
On 01 Feb 2013, at 10:30 , Rémi Després wrote:
Each of the designs we are interested in depends, to be complete,
on reservation of a subset of the IID space left unused by RFC4291
(that having u=g=1).
Both are *experiments*. Neither
Le 2013-02-02 à 16:02, Fernando Gont fg...@si6networks.com a écrit :
On 02/02/2013 07:40 AM, Rémi Després wrote:
Both are *experiments*. Neither is a standard.
With respect to Softwire, they decided to standardise
something other than 4rd. Had they decided to
standardise 4rd, my views
On 31 Jan 2013, at 13:11 , Rémi Després wrote:
What ensures 4rd doesn't conflict with ILNP isn't at all
that ILNP only uses u=0.
It is that, in ILNP, no u=g=1 is used in *unicast* addresses
(those whose IIDs are specified by RFC 4291).
This is still inaccurate.
I REALLY would be
Ran,
I looked at the ILNP RFCs while we were preparing draft-carpenter-6man-ug-00,
and it seemed to me that ILNP doesn't in fact use IIDs, but rather
a redefinition of the bottom 64 bits as a Node Identifier [RFC6741].
Doesn't that separate the use of the u/g bits for ILNP completely
from their
On 01 Feb 2013, at 09:37 , Brian E Carpenter wrote:
I looked at the ILNP RFCs while we were preparing
draft-carpenter-6man-ug-00, and it seemed to me that
ILNP doesn't in fact use IIDs, but rather a redefinition
of the bottom 64 bits as a Node Identifier [RFC6741].
ILNPv6 changes the
Ran,
Going directly to your conclusion, it appears we have a clear common interest!
Each of the designs we are interested in depends, to be complete, on
reservation of a subset of the IID space left unused by RFC4291 (that having
u=g=1).
Since you talk about a small portion of this space for
On 01/02/2013 15:26, RJ Atkinson wrote:
On 01 Feb 2013, at 09:37 , Brian E Carpenter wrote:
I looked at the ILNP RFCs while we were preparing
draft-carpenter-6man-ug-00, and it seemed to me that
ILNP doesn't in fact use IIDs, but rather a redefinition
of the bottom 64 bits as a Node
On 01 Feb 2013, at 10:30 , Rémi Després wrote:
Each of the designs we are interested in depends, to be complete,
on reservation of a subset of the IID space left unused by RFC4291
(that having u=g=1).
Both are *experiments*. Neither is a standard.
With respect to Softwire, they decided to
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
agree with what Ray says. that gives a path forward for 4rd without requiring
us to settle the interface-id structure question.
cheers,
Ole
On Jan 31, 2013, at 11:26 , Ray Hunter v6...@globis.net wrote:
GangChen mailto:phdg...@gmail.com
31 January 2013 08:53
2013/1/30, Ray Hunter
2013-01-31 11:26, Ray Hunter v6...@globis.net :
GangChen mailto:phdg...@gmail.com
...
Just some comments from operational views. I guess it's true operators
could avoid confliction with u=1 g=1 in near future. However, I
believe that is relative short-term guarantee with the condition of
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
Ray,
Thanks for the acknowledgements of point that are now understood.
More clarification inline on others.
2013-01-31 12:32, Ray Hunter v6...@globis.net :
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
2013-01-31 11:42, Ole Troan otr...@employees.org :
agree with what Ray says. that gives a path forward for 4rd without requiring
us to settle the interface-id structure question.
Do you mean by this that 4rd will work perfectly well _without_ this
reservation?
- If not, please clarify
Rémi Després mailto:despres.r...@laposte.net
31 January 2013 15:44
2013-01-31 11:42, Ole Troan otr...@employees.org :
agree with what Ray says. that gives a path forward for 4rd without
requiring us to settle the interface-id structure question.
Do you mean by this that 4rd will work
On Thu, Jan 31, 2013 at 10:42 AM, Ole Troan otr...@employees.org wrote:
agree with what Ray says. that gives a path forward for 4rd without requiring
us to settle the interface-id structure question.
For what it's worth, I also agree with Ray.
Nothing brought forward by or from 4rd have
2013-01-31 16:35, Ray Hunter v6...@globis.net:
Rémi Després mailto:despres.r...@laposte.net
31 January 2013 15:44
2013-01-31 11:42, Ole Troan otr...@employees.org :
agree with what Ray says. that gives a path forward for 4rd without
requiring us to settle the interface-id structure
Ran,
Oops!
I must really apologize for having given a wrong reason why 4rd doesn't
conflict with ILNP as specified by RFCs.
(I didn't check yesterday what I had understood, some time ago, after reading
some of the ILNP RFCs, and definitely mischaracterized the reason).
What ensures 4rd
Hello Ray,
2013/1/31, Ray Hunter v6...@globis.net:
GangChen mailto:phdg...@gmail.com
31 January 2013 08:53
2013/1/30, Ray Hunter v6...@globis.net:
inline.
Ole Troan wrote:
Brian,
- If agreed on the principle, and if no one else volunteers, I can
be
available to propose a draft to this
2013-01-29 18:28, Ole Troan otr...@employees.org :
...
I still think we need to answer the question Brian raised.
should the interface-id have any encoded meaning?
That will not be done overnight. I've been thinking about it and
have some ideas about how to write a discussion draft, but
Remi,
I still think we need to answer the question Brian raised.
should the interface-id have any encoded meaning?
That will not be done overnight. I've been thinking about it and
have some ideas about how to write a discussion draft, but it is
unfortuante to make the 4rd work queue behind
Hi,
if we agree that the interface-id is just 64bits of nothingness, then there
is no such thing as an unused IID space.
pick whatever you like for the 4rd IID, but your protocol needs to deal with
collisions.
Dealing with collisions is very probably necessary anyway (virtual machine
Le 2013-01-30 à 14:34, Ole Troan otr...@employees.org a écrit :
Remi,
I still think we need to answer the question Brian raised.
should the interface-id have any encoded meaning?
That will not be done overnight. I've been thinking about it and
have some ideas about how to write a
inline.
Ole Troan wrote:
Brian,
- If agreed on the principle, and if no one else volunteers, I can be
available to propose a draft to this effect.
Seems reasonable.
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having u=1 is reserved. This leaves plenty of
2013/1/30, Ray Hunter v6...@globis.net:
inline.
Ole Troan wrote:
Brian,
- If agreed on the principle, and if no one else volunteers, I can be
available to propose a draft to this effect.
Seems reasonable.
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having
[...]
- If agreed on the principle, and if no one else volunteers, I can be
available to propose a draft to this effect.
Seems reasonable.
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having u=g=1 is reserved. This leaves plenty of space for future
uses of
Hi,
I still think we need to answer the question Brian raised.
should the interface-id have any encoded meaning?
I don't see any benefit of certain bits in the interface-id having special
meanings, but that might be because of a lack of vision on my side :-)
- Sander
On 29/01/2013 13:18, Ole Troan wrote:
[...]
- If agreed on the principle, and if no one else volunteers, I can be
available to propose a draft to this effect.
Seems reasonable.
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having u=g=1 is reserved. This leaves
Brian,
- If agreed on the principle, and if no one else volunteers, I can be
available to propose a draft to this effect.
Seems reasonable.
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having u=g=1 is reserved. This leaves plenty of space for future
uses of
should the interface-id have any encoded meaning?
having spent a decade+ fighting to throw magic bits out of ipv6
addressing (remember tla?), i find this disturbing.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
On 01/29/2013 10:18 AM, Ole Troan wrote:
[...]
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having u=g=1 is reserved. This leaves plenty of space for future
uses of IIDs having u=1, as explicitly expected in RFC 4291.
That goes to the argument of (d), that it
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Rémi Després
Sent: Monday, January 21, 2013 8:20 AM
To: Bob Hinden
Cc: 6man 6man-wg
Subject: 4rd IID range IPv6 addressing architecture
Hi, Bob,
The discussion on whether the proposed
Hi, Bob and 6man,
We do need an answer from 6man to move forward. So far, in my understanding,
6man has not answered the requirement/question raised by softwire chair.
Personally, I support the proposal to reserve a 4rd IID range (we can have max
16 fixed bit in order to reduce the reserved
33 matches
Mail list logo
