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

[Alexandru Petrescu <[e-mail]>]

Le 07/01/2014 18:10, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:[e-mail]]
>> Sent: Tuesday, January 07, 2014 8:58 AM
>> To: Templin, Fred L; [e-mail]
>> Subject: Re: [Fwd: I-D Action: draft-carpenter-6man-why64-00.txt]
>>
>> 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.
>
> RFC4861 says:
>
>     "Unless specified otherwise (in a document that covers operating IP
>     over a particular link type) this document applies to all link types.
>     However, because ND uses link-layer multicast for some of its
>     services, it is possible that on some link types (e.g., Non-Broadcast
>     Multi-Access (NBMA) links), alternative protocols or mechanisms to
>     implement those services will be specified (in the appropriate
>     document covering the operation of IP over a particular link type).
>     The services described in this document that are not directly
>     dependent on multicast, such as Redirects, Next-hop determination,
>     Neighbor Unreachability Detection, etc., are expected to be provided
>     as specified in this document.  The details of how one uses ND on
>     NBMA links are addressed in [IPv6-NBMA].  In addition, [IPv6-3GPP]
>     and[IPv6-CELL] discuss the use of this protocol over some cellular
>     links, which are examples of NBMA links."
>
> ISATAP is a document that covers operating IP over a particular link
> type. ISATAP links are NBMA, and ISATAP specifies the operation of
> IPv6 ND over that link type.
>
>> (a more real IP-over-foo document would have e.g. a particular PHY).
>
> ISATAP links are very real; the PHY is the underlying IPv4 site.

I don't doubt ISATAP links are real links which transport real packets.

But a PHY would have a specific encoding scheme (OFDM, TDMA, etc.), 
which IPV4 had not.

Alex

>
> Thanks - Fred
> [e-mail]
>
>> 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
>>>> --------------------------------------------------------------------
>>>
>>>
>>
>
>