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

["Templin, Fred L" <[e-mail]>]

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.

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
> >> --------------------------------------------------------------------
> >
> >
>