Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]

[Alexandru Petrescu <[e-mail]>]

Hi Fred,

Le 07/01/2014 16:59, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message-----
>> From: ipv6 [mailto:[e-mail]] On Behalf Of Alexandru Petrescu
>> Sent: Tuesday, January 07, 2014 5:23 AM
>> To: [e-mail]
>> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]
>>
>> Le 06/01/2014 17:07, Templin, Fred L a écrit :
>>> Hello Brian and co-authors,
>>>
>>> The draft looks good to me. In Section 3, paragraph 3, please
>>> add ISATAP [RFC5214] and AERO [I-D.templin-aerolink] to the
>>> list of "IPv6-over-foo" documents.
>>
>> Hi Fred,
>>
>> Yes, IID of ISATAP RFC5214 reads as fixed 64bit long, and should be cited.
>>
>> However, I am not sure ISATAP would apply to be an 'IPv6-over-foo'
>
> ISATAP specifies the formation of IPv6 interface identifiers and the
> operation of IPv6 neighbor discovery over a link type that supports
> the transmission of IPv6 packets, so it fits the description of IPv6
> over (foo).

Sounds more like the IPv6-over-PPP part of the IP-over-foo family, in 
that PPP like ISATAP link layer is a sort of a dummy virtual link.  (a 
more real IP-over-foo document would have e.g. a particular PHY).

Let's see where we'll put this reference.

>> document.  Rather a v4-v6 transition mechanism?
>
> Some sites that deploy ISATAP may find the service acceptable to the
> point that they never have to take it down and move onto native IPv6.
> I think that's part of the reason why there is so much teeth-gnashing
> among the haters who have pushed back on ISATAP over the years.
>
>> If yes we have this
>> text that could  be augmented with ISATAP reference:
>>>     IPv6 transition mechanisms such as NAT64 and NPTv6, as well as Basic
>>>     transition and Teredo rely on the use of IIDs of length 64.
>>
>> On another hand,  draft-templin-aerolink-00.txt seems to be an
>> IPv6-over-foo document.  I need to read this part more to better
>> understand the suggestion. I will come back.
>
> OK - thanks.

Ok, let's see.

Alex

>
> Fred
> [e-mail]
>
>> Thanks for the suggestion.
>>
>> Alex
>>
>>>
>>> Thanks - Fred
>>> [e-mail]
>>>
>>>> -----Original Message-----
>>>> From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
>>>> Sent: Sunday, January 05, 2014 2:07 PM
>>>> To: 6man
>>>> Subject: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]
>>>>
>>>> Hi,
>>>>
>>>> A group of us put this together following a discussion some weeks
>>>> ago on the v6ops list about the 64-bit boundary in IPv6 addresses.
>>>> Discussion belongs in 6man, please.
>>>>
>>>> This draft is incomplete but we'd welcome input. Let me underline
>>>> an important comment in the introduction:
>>>>
>>>>     _The purpose of this document is to analyse the issues around this
>>>>      question.  We make no proposal for change, but we do analyse the
>>>>      possible effects of a change._
>>>>
>>>>
>>>>      Brian + co-authors
>>>>
>>>> -------- Original Message --------
>>>> Subject: I-D Action: draft-carpenter-6man-why64-00.txt
>>>> Date: Sun, 05 Jan 2014 13:59:17 -0800
>>>> From: [e-mail]
>>>> Reply-To: [e-mail]
>>>> To: [e-mail]
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>           Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
>>>>           Authors         : Brian Carpenter
>>>>                             Tim Chown
>>>>                             Fernando Gont
>>>>                             Sheng Jiang
>>>>                             Alexandru Petrescu
>>>>                             Andrew Yourtchenko
>>>> 	Filename        : draft-carpenter-6man-why64-00.txt
>>>> 	Pages           : 14
>>>> 	Date            : 2014-01-05
>>>>
>>>> Abstract:
>>>>      The IPv6 unicast addressing format includes a separation between the
>>>>      prefix used to route packets to a subnet and the interface identifier
>>>>      used to specify a given interface connected to that subnet.
>>>>      Historically the interface identifier has been defined as 64 bits
>>>>      long, leaving 64 bits for the prefix.  This document discusses the
>>>>      reasons for this fixed boundary and the issues involved in treating
>>>>      it as a variable boundary.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-carpenter-6man-why64/
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-carpenter-6man-why64-00
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>