On 12/20/2012 03:04 PM, Templin, Fred L wrote:
>> On 12/18/2012 04:13 PM, Templin, Fred L wrote:
>>> I have a question about this document. Is a middlebox permitted
>>> to fragment an "atomic" fragment before forwarding the packet
>>> on to the next hop? If not, why not - after all, that's why the
Hi, Fred,
On 12/19/2012 02:41 PM, Templin, Fred L wrote:
> I am thinking of the case of links (e.g., tunnels) in the middle
> of the network that must perform link adaptation in order to meet
> the 1280 byte minimum IPv6 MTU. For example, if a tunnel is
> configured over a link that has an MTU les
Hosnieh,
On 12/20/2012 06:06 PM, Rafiee, Hosnieh wrote:
> Now the question is whether or not you are using the "lifetime" for this
> IID or IP. If you are, then it is the same procedure as that for the RFC
> privacy extension.
The lifetime advertised in RA messages? - Of course.
>>Nobody has e
Bob, and Ole,
Thanks so much for your detailed review! Please find my comments in-line
On 12/20/2012 11:40 AM, Ole Troan wrote:
> General comments:
> --
> We do see the usefulness of a interface-id generation algorithm, that
> results
> in stable identifiers per IPv6 p
Correction to prior comment
Ole and Bob: I do think that the extension to the Privacy Extension RFC is
applicable here.
...
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/
Ole and Bob: I don't think that the extension to the Privacy Extension RFC is
applicable here.
Fernando:
I think some of these comments were also made by Ole and Bob but, as I was so
busy, I could not finish them and send them.
Now the question is whether or not you are using the "lifetime" fo
- 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:
>
"The IID consists of N bits th
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
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
Hello again, 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-f
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
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
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
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
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
all,
the ADs have asked us to ensure that there are good review of documents in the
working group, prior to them being advanced to the IESG.
as a part of document last calls in the 6man working group, Bob and I want to
try
using volunteers and/or w.g. chair reviewers, that take specific responsib
2012-12-20 13:46, Ole Troan :
>>> 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 than
>> "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
>> 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 than making any assumption abut the u/g flags.
Le 2012-12-20 à 11:44, Brian E Carpenter a écrit :
> Rémi,
>
> I think this might work, and is nicely orthogonal to my question
> whether the u/g bits have any intrinsic value.
>
> One question though. You suggest
> 0300:::-03FF:::
> but I understand that 4rd needs 6 by
Rémi,
I think this might work, and is nicely orthogonal to my question
whether the u/g bits have any intrinsic value.
One question though. You suggest
0300:::-03FF:::
but I understand that 4rd needs 6 bytes, not 7.
Is there any reason you did not propose
0300:::
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 pa
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
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
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
> > 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
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,
>>
27 matches
Mail list logo
