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
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
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
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
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 should decide
explicitly which one we want.
Hi, Brian,
On 12/18/2012 01:32 PM, Brian Haberman wrote:
>> Thanks so much for your feedback! -- Please find my comments inline...
>>
>>
>> On 12/13/2012 03:57 PM, Brian Haberman wrote:
>>> Substantive
>>>
>>>
>>> * It would be quite useful to explicitly define "atomic fragment"
Hi, Fred,
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
> host inserted the fragment header in the fi
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
host inserted the fragment header in the first place. If so,
then shouldn't the draft say something about the
Yes, thanks.
Regards
Brian Carpenter
On 18/12/2012 14:53, Fernando Gont wrote:
> On 12/18/2012 11:35 AM, Brian E Carpenter wrote:
>>> Agreed. What I meant in my response to Hosnieh is that these addresses
>>> behave (in terms of lifetimes) in the same way as traditional slaac
>>> addresses, bu
On 12/17/12 10:54 AM, Fernando Gont wrote:
Hi, Brian,
Thanks so much for your feedback! -- Please find my comments inline...
On 12/13/2012 03:57 PM, Brian Haberman wrote:
Substantive
* It would be quite useful to explicitly define "atomic fragment" prior
to using it in the d
On 12/18/2012 11:35 AM, Brian E Carpenter wrote:
>> Agreed. What I meant in my response to Hosnieh is that these addresses
>> behave (in terms of lifetimes) in the same way as traditional slaac
>> addresses, but do not vary over time as RFC4941-addresses.
>>
>> So it's not clear to me what's the c
On 18/12/2012 14:40, Ole Troan wrote:
>> The concern is that we are still mainly ignoring the renumbering
>> problem, and in some years time this will be serious for users.
>> But if you add "From the point of view of renumbering, these addresses
>> behave like RFC4941 addresses" the point is cover
> The concern is that we are still mainly ignoring the renumbering
> problem, and in some years time this will be serious for users.
> But if you add "From the point of view of renumbering, these addresses
> behave like RFC4941 addresses" the point is covered.
... behave like RFC4862 addresses.
c
On 18/12/2012 14:13, Fernando Gont wrote:
> On 12/18/2012 10:55 AM, Ole Troan wrote:
> Nobody even suggested that. For instance, if these addresses had a
> lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the
> first place.
I suggest that you add a discussion of
On 12/18/2012 10:55 AM, Ole Troan wrote:
Nobody even suggested that. For instance, if these addresses had a
lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the
first place.
>>>
>>> I suggest that you add a discussion of site renumbering considerations.
>>> The pr
>>> Nobody even suggested that. For instance, if these addresses had a
>>> lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the
>>> first place.
>>
>> I suggest that you add a discussion of site renumbering considerations.
>> The problems described in draft-ietf-6renum-static-p
Hi, Brian,
On 12/18/2012 05:06 AM, Brian E Carpenter wrote:
> On 18/12/2012 02:01, Fernando Gont wrote:
> ...
>> Nobody even suggested that. For instance, if these addresses had a
>> lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the
>> first place.
>
> I suggest that you ad
On 18/12/2012 02:01, Fernando Gont wrote:
...
> Nobody even suggested that. For instance, if these addresses had a
> lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the
> first place.
I suggest that you add a discussion of site renumbering considerations.
The problems describe
18 matches
Mail list logo
