,
RD
Regards
Brian
On 11/02/2013 10:13, Rémi Després wrote:
Hi, Bob, Ole,
RFC 6164 (/127 on inter-router links) is in fact an update of RFC4291 (IPv6
addressing architecture).
Yet, it isn't listed as such in https://tools.ietf.org/html/rfc4291.
Shouldn't this be fixed?
Regards
Hi, Usman,
Thank you for this opportunity to clarify once more an important point.
2013-02-09 03:16, Usman Latif osma...@yahoo.com :
Hi Remi,
A few months ago, I raised some concerns around RFC 6164 which permitted use
of /127 prefixes on inter-router p2p links.
You mention use of u/g
2013-02-07 19:35, Roger Jørgensen rog...@gmail.com :
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 despres.r...@laposte.net wrote:
snip
(b) The benefit comes from the following, i.e. one of the 4rd objectives:
- We want
2013-02-08 à 10:51, sth...@nethelp.no :
... 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
Le 2013-02-08 à 11:59, Havard Eidnes h...@uninett.no a écrit :
However, there is nothing which enforces RFC4291-conforming IIDs for
(for instance) statically configured IPv6-addresses.
So in what way do
well defined u/g values for RFC4291-conforming IIDs help you?
1.
Users that manually
Le 2013-02-08 à 12:08, Roland Bless roland.bl...@kit.edu a écrit :
Hi,
On 08.02.2013 09:31, Rémi Després wrote:
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
Le 2013-02-06 à 22:12, Roland Bless roland.bl...@kit.edu a écrit :
...
Nothing new needs to be done in any implementation other than that of a
4rd-supporting devices (4rd CEs and BRs).
In case that they are
not using 4rd, MUST they exclude this IID range?
Because of RFC 4291 is as it
2013-02-06 17:28, Ole Troan o...@cisco.com :
Fernando,
...
with Remi's proposal, a duplicate address will not even be detected.
Correct: even if software is available to detect collisions between 4rd
addresses and RFC 4291-compatible host addresses, it won't detect any. (Such
software,
2013-02-07 14:41, Ole Troan o...@cisco.com :
Remi,
...
with Remi's proposal, a duplicate address will not even be detected.
Correct: even if software is available to detect collisions between 4rd
addresses and RFC 4291-compatible host addresses, it won't detect any. (Such
software,
2013-02-07 15:04, Ole Troan o...@cisco.com :
I think our understanding of the IPv6 addressing architecture is incompatible.
there are no unused subset or unused ranges of interface-ids in IPv6.
1. If you interpret RFC 4291 as already permitting to set u=1 in some IIDs
other than derived
2013-02-07 16:34, Ray Hunter v6...@globis.net :
Ole Troan wrote:
Remi,
...
I think our understanding of the IPv6 addressing architecture is
incompatible.
there are no unused subset or unused ranges of interface-ids in IPv6.
cheers,
Ole
FWIW I agree with Ole.
An IID currently only
Le 2013-02-07 à 17:55, Doug Barton do...@dougbarton.us a écrit :
On 02/07/2013 06:01 AM, Rémi Després wrote:
Besides, these remaining concerns are aside from the question asked by
Softwire
Rémi,
Do you admit to the possibility that the design coming from softwire might
have flaws
Le 2013-02-07 à 18:02, Doug Barton do...@dougbarton.us a écrit :
Rémi,
I think you've misunderstood me. Please see below.
On 02/06/2013 02:01 AM, Rémi Després wrote:
...
Fair enough. My answer is that no software that I know makes
determination based on the u bit.
Thanks
2013-02-06 00:45, Doug Barton do...@dougbarton.us :
On 02/05/2013 05:57 AM, Rémi Després wrote:
Hi, Doug,
Please see inline.
2013-02-04 à 18:37, Doug Barton do...@dougbarton.us :
On 02/04/2013 12:38 AM, Rémi Després wrote:
It remains that IIDs having u=1 SHOULD be unique, i.e
Bob,
This is, in my understanding, what should be avoided in 6man, a debate on new
4rd modifications:
- The 4rd design has been stabilized for long in Softwire.
- The question to 6man is ONLY whether the proposed reserved range is
compatible with the IPv6 addressing architecture.
Thanks,
RD
2013-02-06 à 13:07, Bless, Roland (TM) roland.bl...@kit.edu :
Dear Rémi,
Am 06.02.2013 11:13, schrieb Rémi Després:
This is, in my understanding, what should be avoided in 6man, a debate on
new 4rd modifications:
- The 4rd design has been stabilized for long in Softwire.
- The question
Le 2013-02-06 à 17:16, Fernando Gont ferna...@gont.com.ar a écrit :
On 02/06/2013 10:52 AM, Rémi Després wrote:
- The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a
tool to RESOLVE them when they occur.
DAD *detects* them, but does not resolve them (for instance
2013-02-06 17:41, Bless, Roland (TM) roland.bl...@kit.edu :
Hi,
Am 06.02.2013 14:52, schrieb Rémi Després:
As already said, the 4rd range only makes a first use of an existing
RFC4291 provision: The use of the universal/local bit in the
Modified EUI-64 format identifier is to allow
Hi, Doug,
Please see inline.
2013-02-04 à 18:37, Doug Barton do...@dougbarton.us :
On 02/04/2013 12:38 AM, Rémi Després wrote:
It remains that IIDs having u=1 SHOULD be unique, i.e. with rare enough
exceptions. This is somewhat similar to the expectation that ULA collisions
shouldn't
Le 2013-02-05 à 15:01, sth...@nethelp.no a écrit :
With these specifications, it is impossible on a SLAAC link that two hosts
that have universal-scope addresses (necessarily different if they
communicate at the MAC layer), would have conflicting IIDs at the IP layer
if they derive them
Bob,
It seems the general discussion on u/g-bits clarification is going to be long.
Fortunately it also appears, for instance in the following, that compatibility
of the 4rd IID-range with the IPv6 addressing architecture doesn't depend on
this work being completed.
2013-02-05 15:36, Brian
.
(Despite my understanding that the point I had made below isn't contradictory
with (a) and (b) above, I see no point in arguing more about it.)
Thanks,
RD
Le 2013-02-05 à 15:36, Brian E Carpenter brian.e.carpen...@gmail.com a écrit :
On 05/02/2013 14:11, Rémi Després wrote:
Le 2013-02-05 à 15:01
Brian, Bob,
2013-02-03 12:43, Brian E Carpenter brian.e.carpen...@gmail.com :
On 03/02/2013 10:57, Rémi Després wrote:
Le 2013-02-02 à 18:17, Joel M. Halpern j...@joelhalpern.com a écrit :
I a not clear what aspect of the semantics of u==1 and the relationship to
EUI-64 is a dead duck
2013-02-03 à 20:39, Joel M. Halpern j...@joelhalpern.com :
On 2/3/2013 2:36 PM, Brian E Carpenter wrote:
On 03/02/2013 17:26, Joel M. Halpern wrote:
To a significant degree Randy, I agree with you in your comment about
magic bits. If I were designing IPv6 from scratch (counter-factual
Hi, Roger,
Please see inline.
2013-02-03 22:40, Roger Jørgensen rog...@gmail.com :
On Sun, Feb 3, 2013 at 9:56 PM, joel jaeggli joe...@bogus.com wrote:
On 2/3/13 11:39 AM, Joel M. Halpern wrote:
On 2/3/2013 2:36 PM, Brian E Carpenter wrote:
On 03/02/2013 17:26, Joel M. Halpern wrote:
To
Randy,
We have in common, as you know, the objective of IPv6 promotion, and that of
NATs elimination as much as possible.
In this respect, changing now the IPv6 specification for hosts that configure
IIDs having u=1, although no serious need has been identified, and this
specification has
2013-02-04 10:41, Fernando Gont fg...@si6networks.com :
On 02/04/2013 06:11 AM, Rémi Després wrote:
It depends on what is done with the new design, especially if it is backward
compatible and optional.
The question that started this discussion is whether reserving a currently
unused
Le 2013-02-04 à 10:54, Fernando Gont fg...@si6networks.com a écrit :
On 02/04/2013 05:38 AM, Rémi Després wrote:
(*) It remains that IIDs having u=1 SHOULD be unique, i.e. with rare
enough exceptions. This is somewhat similar to the expectation that
ULA collisions shouldn't be seen
2013-02-04 11:37, Fernando Gont fg...@si6networks.com :
On 02/04/2013 06:56 AM, Rémi Després wrote:
I believe that the original question really was whether it makes
sense to reserve an unused IID range for 4rd.
A 4rd reserved range, for 4rd activation to never require IPv6
renumbering
Le 2013-02-04 à 11:32, Fernando Gont fg...@si6networks.com a écrit :
On 02/04/2013 06:42 AM, Rémi Després wrote:
In this respect, changing now the IPv6 specification for hosts that
configure IIDs having u=1, although no serious need has been
identified, and this specification has ben used
Brian,
I agree that this is a good time to clarify uses of u and g bits, and support
the initiative Sheng and yourself has taken.
Comments and suggestions inline.
2013-02-01 21:13, Fernando Gont fg...@si6networks.com :
Hi, Brian Sheng,
On 02/01/2013 05:13 AM, Brian E Carpenter wrote:
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
2013-02-02 12:46, Brian E Carpenter brian.e.carpen...@gmail.com :
...
IMHO The only combination that has operational value for the purpose of
mapping IPv6 address to MAC today is:
u==1 g==0 (concatenated with unicast IPv6/64 prefix[2000::/3] ||
link local address [fe80::/10]) SLAAC
Le 2013-02-02 à 14:45, Ray Hunter v6...@globis.net a écrit :
...
In any case, and more important in my understanding, this doesn't change
that any IID having u=1 can never conflict with IEEE-derived IIDs, be they
duplicated or not. A clarification on this would IMHO be useful.
I have a
for ILNP, and since 4rd
only needs only 1/2^14 of this space, I rather see convergence than conflict.
Hoping we can agree on it,
Regards,
RD
A few secondary comments inline.
2013-02-01 14:54, RJ Atkinson rja.li...@gmail.com :
On 31 Jan 2013, at 13:11 , Rémi Després wrote:
What ensures 4rd
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
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
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
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
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
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
Hi, Bob,
The discussion on whether the proposed 4rd IID range is compatible with the
IPv6 addressing architecture has apparently come to a standstill.
Yet an answer of 6man to Softwire is expected.
A. To help making a WG decision, here are key points that, in my understanding,
emerged from the
may be constructed by turning on
the Group bit, and unicast identifiers constructed by leaving the
Group bit zero.
Hope this helps,
It does (IMHO). Thanks for this reference.
Regards,
RD
RayH
Quoting Rémi Després despres.r...@laposte.net:
Ray,
Please see inline.
2012-12-21 à
Roger,
Please se inline.
2012-12-2122:12, Roger Jørgensen rog...@gmail.com :
On Fri, Dec 21, 2012 at 2:57 PM, Rémi Després despres.r...@laposte.net
wrote:
2012-12-2110:49, Ole Troan otr...@employees.org :
...
(*)
4rd implementors are free to add code to reject any intra-site IID
2012-12-20 19:34, Fred Baker (fred) f...@cisco.com :
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
2012-12-20 20:29, Ole Troan otr...@employees.org :
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
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.
Le 2012-12-21 à 10:37, Ole Troan otr...@employees.org 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.
Hi, Simon,
Thanks a lot for this pointer.
I will check, hopefully with Brian, which 4rd range can best fit in this
up-to-date table.
RD
Le 2012-12-21 à 11:56, Simon Perreault simon.perrea...@viagenie.ca a écrit :
Le 2012-12-20 11:07, Rémi Després a écrit :
- Small problem: at http
Ray,
Please see inline.
2012-12-21 à 14:03, Ray Hunter v6...@globis.net :
...
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
2012-12-2110:49, Ole Troan otr...@employees.org :
...
(*)
4rd implementors are free to add code to reject any intra-site IID that (by
mistake) would be universal-scope, and in the 4rd-assigned IID range.
but the current specification does not handle conflicts?
There is no relation
2012-12-21 12:00, Ole Troan otr...@employees.org :
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
, IANA can be required to add this
range to its table of
www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml (Thanks to
Simon for having found where it is).
Regards,
RD
2012-12-21 11:56, Simon Perreault simon.perrea...@viagenie.ca :
Le 2012-12-20 11:07, Rémi Després
2012-12-20 à 16:50, Bless, Roland (TM) roland.bl...@kit.edu :
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
that are
understood to not disrupt any implementation that complies with existing RFCs.
Regards,
RD
Thanks
Suresh
On 12/20/2012 05:07 AM, Rémi Després wrote:
Hello, chairs,
- First a great thank you Jouni for for the reference to RFC 5453, which is
perfectly relevant but had been ignored
2012-12-19 23:01, Roger Jørgensen rog...@gmail.com :
...
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.
2012-12-19 21:27, Bless, Roland (TM) roland.bl...@kit.edu :
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
Hello, chairs,
- First a great thank you Jouni for for the reference to RFC 5453, which is
perfectly relevant but had been ignored in this discussion.
The good news is that, since an IANA registry for IID ranges has already been
created, no new registry is needed for any new IID type, and in
, is there any reason not to choose (for example)
FDFE:::-FDFE:::
which is near the existing anycast range ?
No objection that I can see.
Support for including this in the 6man answer.
Thanks,
RD
Regards
Brian
On 20/12/2012 10:07, Rémi Després wrote:
Hello
2012-12-20 13:46, Ole Troan otr...@employees.org:
Also, is there any reason not to choose (for example)
FDFE:::-FDFE:::
which is near the existing anycast range ?
No objection that I can see.
Support for including this in the 6man answer.
I think this is better
Fred,
Please see inline.
2012-12-20 à 17:32, Fred Baker (fred) f...@cisco.com :
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
Hello, Ray,
2012-12-19 09:57, Ray Hunter v6...@globis.net :
...
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
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
2012-12-19 16:58, Brian E Carpenter brian.e.carpen...@gmail.com :
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
2012-12-13 21:05, RJ Atkinson rja.li...@gmail.com :
On 13 Dec 2012, at 10:46 , Rémi Després wrote:
Reverse mapping, whose use I still don't see,
cannot work the privacy option of RFC 4941
It still works fine, because the scope bit
is set to local scope for the RFC-4941 uses
(RFC-4941
2012-12-12 18:26, Ran Atkinson ran.atkin...@gmail.com :
On 12 Dec 2012, at 12:21 , Rémi Després wrote:
Do you know any deployment with u=g=1 in this context ?
There is limited use today of IPv6 addresses that have
apparent unicast routing prefixes, but contain multicast
group IDs
2012-12-12 18:38, RJ Atkinson rja.li...@gmail.com :
On 12 Dec 2012, at 12:14 , Rémi Després wrote:
In any case, IIDs for multicast addresses are out of scope for the IPv6
addressing architecture of RFC 4291.
Disagree. It is clear that RFC-4291 has reserved
the use of G==U==1
,
Bob
On Dec 11, 2012, at 6:35 AM, Rémi Després wrote:
Hi Brian,
Thank you for the quick comments on this issue.
Let me explain more below.
2012-12-11 11:55, Brian E Carpenter brian.e.carpen...@gmail.com:
Hi Suresh,
The 4rd draft (http://tools.ietf.org/html/draft-ietf-softwire
Hi, Jouni,
2012-12-12 10:04, Jouni Korhonen jouni.nos...@gmail.com :
Hi,
On Dec 8, 2012, at 2:14 AM, Suresh Krishnan suresh.krish...@ericsson.com
wrote:
Hi all,
The 4rd draft (http://tools.ietf.org/html/draft-ietf-softwire-4rd-04)
describes a solution for providing IPv4
2012-12-12 12:45, Brian E Carpenter brian.e.carpen...@gmail.com :
I think the only way to make progress on this question is to
discuss two points in a much more general way:
1. Does the current mapping of the u bit in the modified EUI format have
any value?
2. Does the current mapping
Le 2012-12-12 à 17:12, Jouni Korhonen jouni.nos...@gmail.com a écrit :
Remi,
On Dec 12, 2012, at 3:29 PM, Rémi Després despres.r...@laposte.net wrote:
Hi, Jouni,
2012-12-12 10:04, Jouni Korhonen jouni.nos...@gmail.com :
Hi,
On Dec 8, 2012, at 2:14 AM, Suresh Krishnan
Le 2012-12-12 à 17:18, Roger Jørgensen rog...@gmail.com a écrit :
On Sat, Dec 8, 2012 at 1:14 AM, Suresh Krishnan
suresh.krish...@ericsson.com wrote:
Hi all,
The 4rd draft (http://tools.ietf.org/html/draft-ietf-softwire-4rd-04)
describes a solution for providing IPv4 connectivity over
2012-12-12 17:06, RJ Atkinson rja.li...@gmail.com :
All,
I fully agree with Brian Carpenter's note of Tuesday,
December 11th at 10:55:05 +. I support his
perspective as expressed in that note.
I have read, but am NOT persuaded by, the responses
from Remi Despres to Brian's notes.
Le 2012-12-12 à 17:23, Ran Atkinson ran.atkin...@gmail.com a écrit :
On Weds 12th December, Remi Despres wrote, in part:
Not sure however that the two proposed questions
are clear enough because today:
- some IIDs have u = 0, and some have u = 1,
- some IIDs have g = 0, and some have g =
Hi Brian,
Thank you for the quick comments on this issue.
Let me explain more below.
2012-12-11 11:55, Brian E Carpenter brian.e.carpen...@gmail.com:
Hi Suresh,
The 4rd draft (http://tools.ietf.org/html/draft-ietf-softwire-4rd-04)
describes a solution for providing IPv4 connectivity over
Le 2012-06-13 à 20:46, Dave Hart a écrit :
I am in favor of adopting draft-gont-6man-oversized-header-chain-02 as
a 6MAN WG document.
+1
RD
Dave Hart
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
Le 2012-06-13 à 20:53, Dave Hart a écrit :
I support advancing draft-ietf-6man-uri-zoneid-01 as a PS.
+1
RD
Dave Hart
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
Le 2012-01-06 à 07:48, Fernando Gont a écrit :
Hi, Rémi,
On 01/05/2012 02:02 PM, Rémi Després wrote:
Hi Fernando,
Full agreement on the substance of your draft, and support for an RFC based
on it.
However, I believe it should rather be a BCP than a Standard-track RFC.
(I don't see
Hi Fernando,
Full agreement on the substance of your draft, and support for an RFC based on
it.
However, I believe it should rather be a BCP than a Standard-track RFC.
(I don't see any need to standardize anything beyond what already exists.)
Regards,
RD
Le 2012-01-04 à 20:36, Fernando Gont
Le 25 juil. 2011 à 20:50, Dan Wing a écrit :
-Original Message-
From: Rémi Després [mailto:despres.r...@laposte.net]
Sent: Monday, July 25, 2011 1:43 PM
To: Dan Wing
Cc: 'james woodyatt'; 'RJ Atkinson'; ipv6@ietf.org
Subject: Re: PMTUD and MTU 1280
Dan,
1.
The point I
Dan,
1.
The point I wanted to check is just, slightly reformulated):
May a simple IPv6 host have no support of packet-reassembly, and simply accept
packets up to 1280 octets.
In my understanding, the answer should be yes.
- This doesn't depend on whether sources know or not whether their
Le 16 mars 2011 à 07:30, Christian Huitema a écrit :
...
In fact, rather than your draft proposing to not use privacy addresses, we
should pursue the deprecation of using EUI-64 in addresses.
-1
The worst part of your draft is that , if we published it, it would give the
impression that
Le 15 janv. 2011 à 23:59, Hing-Kam (Kam) Lam a écrit :
If the firewall will just dig one layer deeper and then discard
anyway, what is the point?
It wouldnt in all the cases - not when the Hdr type is 00.
If the draft is adopted, the more precise situation becomes:
- NEITHER that all FW's
Le 5 janv. 2011 à 13:44, Joel M. Halpern a écrit :
...
I consider (a), specifying the format at least to the level of requiring TLV
encoding, to be a good idea.
+1
IETF IPv6 working group mailing list
ipv6@ietf.org
Le 5 janv. 2011 à 21:15, Brian E Carpenter a écrit :
On 2011-01-06 02:15, RJ Atkinson wrote:
...
Prohibiting new IPv6 Extension Headers outright,
...
My reaction is that this is going too far,
+1
...
So I am more inclined to a SHOULD NOT approach; I think I'm agreeing
with a somewhat
Le 28 oct. 2010 à 07:18, Suresh Krishnan a écrit :
...
I doubt that any new use of the flow label will be backward compatible. Do
you have any text about this proposal that I can read up on?
In my understanding:
- draft-carpenter-flow-ecmp-03 details a promising particular use of 20-bit
Le 28 oct. 2010 à 18:01, Suresh Krishnan a écrit :
...
The proposals need consenting hosts on both ends to be useful, don't they?
They don't!
(Load balancing is a one-way function. If a host sets FLs, its flows to all
destinations can be load balanced with ecmp, independently of what other
Le 27 oct. 2010 à 06:26, Suresh Krishnan a écrit :
Hi Remi,
On 10-10-26 12:24 PM, Rémi Després wrote:
Hi, Suresh,
Le 25 oct. 2010 à 19:57, Suresh Krishnan a écrit :
...
I strongly support the load-balancing use of the flow label.
Isn't it better, then, to quickly improve what we have
Hi, Suresh,
Le 25 oct. 2010 à 19:57, Suresh Krishnan a écrit :
...
I strongly support the load-balancing use of the flow label.
Isn't it better, then, to quickly improve what we have for this, than inventing
new uses that would prevent backward compatibility?
The question is how many bits
Le 23 oct. 2010 à 16:09, Randy Bush a écrit :
1. I do think that the justification in the draft for such a major
change, after 12 years work based on RFC 2460, is weak.
how much do you want for hacking on an unused field, another glorious
pile of second system syndrome, for which dozens of
Support.
RD
Le 9 oct. 2010 à 18:39, Brian Haberman a écrit :
All,
I am starting a one week consensus call on adopting:
Title : Using 127-bit IPv6 Prefixes on Inter-Router Links
Author(s) : M. Kohno, et al.
Filename : draft-kohno-ipv6-prefixlen-p2p-03.txt
Pages
Le 1 oct. 2010 à 02:00, Brian E Carpenter a écrit :
On 2010-09-30 20:01, Rémi Després wrote:
...
Our question is: Is this usage compatible to RFC 3697? We posted this
question to Softwires and we were told to also ask 6man for input.
With RFC 3697 as is, it doesn't seem to be compatible
Le 1 oct. 2010 à 21:35, Brian E Carpenter a écrit :
On 2010-10-01 20:29, Rémi Després wrote:
Le 1 oct. 2010 à 02:00, Brian E Carpenter a écrit :
On 2010-09-30 20:01, Rémi Després wrote:
...
Our question is: Is this usage compatible to RFC 3697? We posted this
question to Softwires and we
Hi Yiu,
Response below, with an added direct copy to Brian.
Le 25 sept. 2010 à 04:14, Yiu L. Lee a écrit :
Hi gents,
We have a design question of Flow Label. During the v6 transition, some DSL
providers may want to create an IPv4-in-IPv6 tunnel from the BRAS to the
AFTR to continue to
Hi,
Le 28 sept. 2010 à 16:52, Hing-Kam (Kam) Lam a écrit :
...
My concern with the current format is that it does not help in incrementally
introducing new v6 extension headers. I would like to add the following to
the list of problems that GIEH currently solves:
*) Some Hdr Options
Le 22 sept. 2010 à 03:06, Christian Huitema a écrit :
no one is arguing nd/ra be removed entirely, as subnet anycast should be.
the argument is that there are environments where it is not needed and
dhcp should be able to be used in its place.
That's reasonable. There are cases where
Le 22 sept. 2010 à 11:24, Mikael Abrahamsson a écrit :
On Wed, 22 Sep 2010, Rémi Després wrote:
Of course, if MS and Apple announce an upgrade of all their IPv6 stacks, to
the effect that they use DHCPv6 requests to obtain what they no longer get
in RAs, that would mitigate the need
1 - 100 of 184 matches
Mail list logo
