Subject: [Fwd: New Version Notification for draft-dickson-v6man-new-autoconf-00]

From: Brian Dickson <[email-masked]>
Date: Thu, 04 Oct 2007 19:40:50 -0400

(Please excuse minor formatting issues and the occasional spelling 
mistake - this is version 00 of the draft.)

This I-D is the one you've all been waiting for, after the "16 bits 
between friends" thread.

Enjoy,

Brian Dickson

Subject: New Version Notification for draft-dickson-v6man-new-autoconf-00
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Date: Thu, 04 Oct 2007 19:20:10 -0400

A new version of I-D, draft-dickson-v6man-new-autoconf-00.txt has been successfuly submitted by Brian Dickson and posted to the IETF repository.

Filename:	 draft-dickson-v6man-new-autoconf
Revision:	 00
Title:		 A New Method of Constructing Interface Identifiers for Expanded Autoconfiguration in IPv6
Creation_date:	 2007-10-04
WG ID:		 Independent Submission
Number_of_pages: 27

Abstract:
This Internet Draft discusses a proposed extension to the set of
Interface Identifier construction methods for 802 networks.  The
purpose of this is to allow autoconf RA announcments of prefix length
other than 64 bits.  It is intended to be fully backward compatible
for /64 announcements.  Instead of having one Interface Identifier
construction method for all purposes, this adds an alternate method
which is only used for autoconf, and only if the prefix length is not
/64.  No other IPv6 methods or protocols require modification.
However, without modification, use of prefixes other than /64 likely
won't support many IPv6 enhanced functions.

The ultimate goal it providing enough bits between the top level
allocation by Regional Internet Registristry (RIR) and the smallest
autoconfiguration allocation, to allow both external aggregation by
ISPs into one prefix, as well as internal hierarchical aggregation to
support a variety of ISP topologies and practices.  Current policies
are driven from below by the current 64 bit Interface Identifier.
Only by relaxing this to 48 bits for such technologies as 802
(Ethernet), does the number of bits available reach a level deemed
"sufficient".Author's Note

This Internet Draft is intended to result in this draft or a related
draft(s) being placed on the Standards Track for 6man.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [5].

The IETF Secretariat.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Sat, 6 Oct 2007 08:43:17 +0930

On Thu, 04 Oct 2007 19:40:50 -0400

> This I-D is the one you've all been waiting for, after the "16 bits 

Couple of quick things from a first glance. I understand Rick Adams is
considered the founder of UUNET, not Mike O'Dell.

You might also want to consider whether you want to quote Mike,
as from what I understand his GSE proposal was the one that suggested
that all node IDs should be the same length universally, separate from variable length prefixes in the routing part of the address.

A internet search has dug up what appears to be a version of that proposal -

http://arneill-py.sacramento.ca.us/ipv6mh/draft-ipng-gseaddr-00.txt

Regards,
Mark.

---

From: [email-masked]
Date: Fri, 5 Oct 2007 19:33:29 -0400 (EDT)

> considered the founder of UUNET, not Mike O'Dell.

Thanks - my memory has apparently failed me in that regard. :-)
It'll get fixed in the next draft. I'll save up a bunch of changes before
modifying it, though, so there's not too much confusion over versions of
the draft.

> that all node IDs should be the same length universally, separate from
> variable length prefixes in the routing part of the address.
>

Actually, I think that's more reason to quote him. The quote is good,
and not everything anyone comes up with is necessarily going to seem as
prophetic after 10 year's time.

The interesting thing in the GSE proposal, was that at the time, IEEE-1394
was seen as a potential take-off point for new devices and addresses.
The large uptake in those devices is, however, largely host-connected
peripherals, rather than network devices - similar to USB in that regard.

I think that re-reading the GSE proposal, with the added perspective that
we have of 10 years' more experience, combined with more recent experiences
and context within which the requirements can be viewed, lends credence to
moving the boundary for the autoconf (host) part of the V6 addresses.

Since we still see the majority of the non-mobile network access devices
as being connected with Ethernet of various flavours, having the ability
to take advantage of that in the numbering, addressing, and allocation &
aggregation, is merely prudent.

I don't actually disagree with the notion of fixed length II's, if the
length chosen is 48 bits. But given the deployed code and connected
networks and hosts, backward compatibility for those exiting sites and
hosts (for 64 bits) is a compromise that I think is reasonable.

If folks would rather only see one II size, then we need to give serious
consideration to changing it universally to 48 bits.

Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Oct 2007 14:57:55 +0200

Hi, some quick comments on this draft, thanks.

> This I-D is the one you've all been waiting for, after the "16 bits 

Use of term 'autoconf' (like in 'autoconf bit', 'the rfcs for autoconf',
'autoconf-specific behaviour', etc) are confusing to a AUTOCONF WG
member who also reads it as address autoconfiguration tools for mobile
ad-hoc networks.  I'd suggest expanding completely the term 'autoconf'
to what you/authors really meant to say.

This draft's section 4.1.1 may list RFC5072's section 4.1 ("IP Version 6
over PPP"), as a potential impact to existing RFCs.

later on draft says:
> OR-ing the prefix with the modified hardware address (e.g. 
> EUI-48/MAC-48 with left-padded zeros)

How about when the hardware address is 48bit but its uniqueness not
guaranteed, because not in the IEEE space.  That is the case for USB
48bit 'MAC' address decided solely by software, not standardized.  There
are other virtual interfaces as well.

I feel the need for that 70th bit 'u'...

> PD is, however, usable by routers in RA announcements, which can then
>  be used by autoconfiguration.

You mean RFC4191 "Default Router Preferences and More-Specific Routes
[in RAs]"?  Or something else?

Thanks,

Alex

> 
> Enjoy,
> 
> Brian Dickson
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> Subject: New Version Notification for 
> draft-dickson-v6man-new-autoconf-00 From: IETF I-D Submission Tool 
> <[email-masked]> Date: Thu, 04 Oct 2007 19:20:10 -0400 To: 
> [email-masked]
> 
> To: [email-masked] CC:
> 
> 
> A new version of I-D, draft-dickson-v6man-new-autoconf-00.txt has 
> been successfuly submitted by Brian Dickson and posted to the IETF 
> repository.
> 
> Filename:	 draft-dickson-v6man-new-autoconf Revision:	 00 Title:		 A
>  New Method of Constructing Interface Identifiers for Expanded 
> Autoconfiguration in IPv6 Creation_date:	 2007-10-04 WG ID: 
> Independent Submission Number_of_pages: 27
> 
> Abstract: This Internet Draft discusses a proposed extension to the 
> set of Interface Identifier construction methods for 802 networks. 
> The purpose of this is to allow autoconf RA announcments of prefix 
> length other than 64 bits.  It is intended to be fully backward 
> compatible for /64 announcements.  Instead of having one Interface 
> Identifier construction method for all purposes, this adds an 
> alternate method which is only used for autoconf, and only if the 
> prefix length is not /64.  No other IPv6 methods or protocols require
>  modification. However, without modification, use of prefixes other 
> than /64 likely won't support many IPv6 enhanced functions.
> 
> draft(s) being placed on the Standards Track for 6man. The key words 
> "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
> "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 
> are to be interpreted as described in [5].
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www1.ietf.org/mailman/listinfo/ipv6 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________