6MAN WG Last Call: <draft-ietf-6man-exthdr-03.txt>

[Resend]

All,

This message starts a two week 6MAN Working Group Last Call on advancing:

	Title           : An uniform format for IPv6 extension headers
	Author(s)       : Suresh Krishnan
                         Erik Kline
                         James Hoagland
                         Manav Bhatia
	Filename        : draft-ietf-6man-exthdr-03.txt
	Pages           : 8
	Date            : 2011-06-27
	
       http://tools.ietf.org/html/draft-ietf-6man-exthdr-03

as a Proposed Standard.  Substantive comments and statements of support for advancing this document
should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call
will end on 14 July 2011.

Regards,
Bob Hinden & Brian Haberman
6MAN Chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Re: 6MAN WG Last Call: <draft-ietf-6man-exthdr-03.txt>

I was a little surprised by this document when I read it. The title
is "An uniform format for IPv6 extension headers", and the abstract
reads as I'd expect. However, when we get to section 3 (Applicability)
"SHOULD" and "MUST" are used, *not* to require people to use a uniform
format for IPv6 extension headers, but instead:

	1) implementations SHOULD use destination options as the
	preferred mechanism for encoding optional destination
	information

	2) The request for creation of a new IPv6 extension header
	MUST be accompanied by an specific explanation of why
	destination options could not be used

	3) new IPv6 Extension Header(s) having hop-by-hop behaviour
	MUST NOT be created or specified

	4) new options for the existing Hop-by-Hop Header SHOULD
	NOT be created or specified unless no alternative is feasible

	5) new optional information to be sent SHOULD be encoded
	in a new option for the existing IPv6 Destination Options
	Header

	6) new IPv6 extension headers MUST NOT be created or
	specified, unless no existing IPv6 Extension Header can be
	used

	7) Any proposal to create or specify a new IPv6 Extension
	Header MUST include a detailed technical explanation of why

Re: 6MAN WG Last Call: <draft-ietf-6man-exthdr-03.txt>

On 30th June 2011, Bob Hinden wrote:
> This message starts a two week 6MAN Working Group Last Call on advancing:
> 
> 	Title           : An uniform format for IPv6 extension headers
> 	Author(s)       : Suresh Krishnan
>                          Erik Kline
>                          James Hoagland
>                          Manav Bhatia
> 	Filename        : draft-ietf-6man-exthdr-03.txt
> 	Pages           : 8
> 	Date            : 2011-06-27
> 	
>        
> http://tools.ietf.org/html/draft-ietf-6man-exthdr-03
> 
> 
> as a Proposed Standard.  Substantive comments and statements of support
> for advancing this document should be directed to the mailing list.  
> Editorial suggestions can be sent to the authors.  This last call
> will end on 14 July 2011.

I support publishing this as a Proposed Standard.  

This revision resolves my earlier concerns that it is
highly undesirable to define *any* new IPv6 Extension Headers
(since defining any new IPv6 Extension Header will break 
multiple existing IPv6 deployments).

On 1st July 2011, David Malone wrote, in part:
> Fixing this could be a simple as changing the title and abstract, 

Re: 6MAN WG Last Call: <draft-ietf-6man-exthdr-03.txt>

On Fri, 2011-07-01 at 10:00 -0400, RJ Atkinson wrote:
> This revision resolves my earlier concerns that it is
> highly undesirable to define *any* new IPv6 Extension Headers
> (since defining any new IPv6 Extension Header will break 
> multiple existing IPv6 deployments).

It seems strange to me that we define "IPv6 Extension Headers", then
refuse to allow any further extensions! That was largely the point and
purpose of the exercise.

That said, it is always "highly undesirable" to make changes to a
deployed protocol UNLESS the changes can safely be ignored. It will
depend on the function of any future extension headers as to whether
they will be able to be safely ignored. On the other hand, if an
extension is needed, then it is needed, and the community will have to
make the tradeoff between the undesirability of a change and the
desirability of a new feature.

This draft means that if an application runs into headers it does not
understand, then at least it can skip them neatly. If *skipping* them
causes problems, then at least the authors *should have* been aware that
new extension headers might come along, and *should have* planned for
that in some way.

Hm, I think I might just have used more words to say what you said 

Regards, K.

--

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: 6MAN WG Last Call: <draft-ietf-6man-exthdr-03.txt>

On 2nd July 2011, Karl Auer wrote, in part:
> It seems strange to me that we define "IPv6 Extension Headers",
> then refuse to allow any further extensions!

Kindly note that this document does NOT prohibit future IPv6 extensions.
That is a mis-understanding of this document.

Please re-read the actual document.

Background:

* IPv6 has always been specified and intended to carry 
  future options and extensions inside the pre-defined "bucket" 
  headers (e.g. Hop-by-Hop Header, Destination Options Header),
  each of which can contain multiple options concurrently.

In slightly more detail...

The document DOES now very clearly define the rules 
for creating new types of *headers*.  These are 
mostly documentation rules.  

	More dangerous behaviours, such as hop-by-hop behaviour, 
	will require more documentation to justify the necessity 
	of the more dangerous behaviour.

In any event, it is important to recall that defining 
a new "header type" is very different from defining 
new IPv6 options or IPv6 extensions.  

Re: 6MAN WG Last Call: <draft-ietf-6man-exthdr-03.txt>

On Sat, 2011-07-02 at 14:39 -0400, RJ Atkinson wrote:
> On 2nd July 2011, Karl Auer wrote, in part:
> > It seems strange to me that we define "IPv6 Extension Headers",
> > then refuse to allow any further extensions!
> 
> Kindly note that this document does NOT prohibit future IPv6 extensions.
> That is a mis-understanding of this document.

I was not taking issue with the document, I was just commenting on your
assertion that it would be "highly undesirable" to create more extension
headers.

Sorry to have been unclear about that.

Regards, K.

--

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer <at> biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

subnet router anycast

Which RFCs (or other sources) describe how IPv6 subnet anycast *works*?
In particular how it works when there are multiple routers in a single
subnet?

Regards, K.

--

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer <at> biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Re: subnet router anycast

Hi,

On 03.07.2011 19:03, Karl Auer wrote:
> Which RFCs (or other sources) describe how IPv6 subnet anycast *works*?
> In particular how it works when there are multiple routers in a single
> subnet?

That's a good question. I was also looking for that. It's distributed
across various RFCs:
-----------------------------------------------------------------------
RFC4291:
   "A node is required to compute and join (on the appropriate interface)
   the associated Solicited-Node multicast addresses for all unicast and
   anycast addresses that have been configured for the node's interfaces
   (manually or automatically)."

RFC 4861:
7.2.7. Anycast Neighbor Advertisements

   From the perspective of Neighbor Discovery, anycast addresses are
   treated just like unicast addresses in most cases.  Because an
   anycast address is syntactically the same as a unicast address, nodes
   performing address resolution or Neighbor Unreachability Detection on
   an anycast address treat it as if it were a unicast address.  No
   special processing takes place.

   Nodes that have an anycast address assigned to an interface treat
   them exactly the same as if they were unicast addresses with two
   exceptions.  First, Neighbor Advertisements sent in response to a
   Neighbor Solicitation SHOULD be delayed by a random time between 0

Re: subnet router anycast

Network Working Group                                            R. Bush
Internet-Draft                                                       IIJ
Intended status: Standards Track                             August 2010
Expires: February 2, 2011

                     IPv6 Subnet Anycast Deprecated
                    draft-ymbk-no-subnet-anycast-00

Abstract

   IPv6 subnet anycast is not used operationally, complicates
   implementations, and complicates protocol specifications.  The form
   of anycast actually used in the Internet is routing-based, and is
   essentilly the same as that of IPv4 anycast.  Therefore, this
   document deprecates IPv6 subnet anycast.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months

Re: subnet router anycast

Hi,

On Sun, 03 Jul 2011 23:50:25 +0200
Roland Bless <roland.bless <at> kit.edu> wrote:

> Hi,
> 
> On 03.07.2011 19:03, Karl Auer wrote:
> > Which RFCs (or other sources) describe how IPv6 subnet anycast *works*?
> > In particular how it works when there are multiple routers in a single
> > subnet?
> 
> That's a good question. I was also looking for that. It's distributed
> across various RFCs:
> -----------------------------------------------------------------------

To make a higher level observation, I don't think it is any different
to the operation of host anycast, as the destination address in the
packet matches one of the router's own addresses, so the router would
process the packet in "host mode" rather than "forwarding mode". 

I suspect it was inspired by Appletalk's assignment of node ID zero on
each cable range to attached routers. That in turn was used by the Name
Binding Protocol for mapping host names to DDP addresses. Since
the goals of Multicast DNS and DNS-based Service Discovery are similar
to NBP, it may be possible that IPv6 router anycast could be used in a
similar way with mDNS and DNS-SD. 

Here's an ID on the topic of NBP/mDNS/DNS-SD -