headers
Internet | 1 Oct 2007 09:00
Picon
Favicon

I-D Action:draft-ietf-v6ops-addcon-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : IPv6 Unicast Address Assignment Considerations
	Author(s)       : C. Systems, et al.
	Filename        : draft-ietf-v6ops-addcon-06.txt
	Pages           : 30
	Date            : 2007-10-01

One fundamental aspect of any IP communications infrastructure is its
addressing plan.  With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network
designers and operators need to reconsider their existing approaches
to network addressing.  Lack of guidelines on handling this aspect of
network design could slow down the deployment and integration of
IPv6.  This document aims to provide the information and
recommendations relevant to planning the addressing aspects of IPv6
deployments.  The document also provides IPv6 addressing case studies
for both an enterprise and an ISP network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-06.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@... with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gunter Van de Velde (gvandeve | 1 Oct 2007 09:11
Picon
Favicon

FW: New Version Notification for draft-ietf-v6ops-addcon-06

 Dear All,

This mail is to note that the fully updated version for the 'IPv6
Address Considerations' and can be found at
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-06.txt

Only change is a note in the appendix:

"All
   subnet sizes used in this appendix are for practical visualization
   and do not dictate RIR policy."

The document was submitted through automatic draft submission tool and 
went through WG Last Call and should be ready for further IESG
progressing. 
Last update -04 to -05 was idnits corrections, while this version was
updated 
with a phrase to disclaim the used IPv6 prefix lenghts in the
case-studies.

We have been receiving notes from people that are awaiting the guidance
in 
this document in RFC format and would lik eto progress forward.

Kind Regards,
G/

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@...] 
Sent: Monday, October 01, 2007 3:54 PM
(Continue reading)

Permalink | Reply | 1 comment |
headers
JINMEI Tatuya / 神明達哉 | 1 Oct 2007 10:07
Picon

Re: [69ATTENDEES] DHCP

At Fri, 28 Sep 2007 11:38:59 -0700,
Bob Hinden <bob.hinden@...> wrote:

> > This is probably an off-topic in this thread (or perhaps for this list
> > in the first place), but just out of curiosity...was the "opposition"
> > of the IPv6 designers the main reason that it took 8 years to complete
> > the DHCPv6 spec?  I didn't even know there was an opposition from the
> > "IPv6 designers" to defining the DHCPv6 protocol.  I recall there was
> > a discussion about whether to mandate implementing DHCPv6 on an IPv6
> > host (and as a result RFC4294 uses a MAY in section 4.5.5), but I
> > don't remember an argument that resisted defining the protocol.
> 
> I think I can claim to be one of the "IPv6 designers".
> 
> My point of view on this is that there was never an opposition to  
> DHCPv6 as described above.  DHCPv6 was always part of the IPv6 plan  
> because we understood that there were going to be environments where  
> it would be important.  For example large enterprises.  There was not  
> any organized effort to delay DHCPv6.  As far as I understand the  
> delay to move DHCPv6 forward was related to activities in the DHC  
> w.g.  I have never been very active in the DHC w.g.

[snip]

> I don't understand how this has been turned into the IPv6 designers  
> delaying DHCPv6 for 8 years.  DHCPv6 is an important part of IPv6.

Thanks for the clarification.  That actually matches my understanding
of the history.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred Baker | 1 Oct 2007 15:08
Picon
Favicon

Re: New Version Notification for draft-ietf-v6ops-addcon-06


On Oct 1, 2007, at 3:11 AM, Gunter Van de Velde (gvandeve) wrote:

> The document was submitted through automatic draft submission tool and
> went through WG Last Call and should be ready for further IESG
> progressing.

thanks.
Permalink | Reply | 0 comments |
headers
Elwyn Davies | 1 Oct 2007 18:49

Security overview published as RFC 4942

The "IPv6 Transition/Coexistence Security Considerations" document has 
now been published as RFC 4942
http://www.ietf.org/rfc/rfc4942.txt?number=4942

Regards,
Elwyn
Permalink | Reply | 0 comments |
headers
Marc Blanchet | 3 Oct 2007 15:13
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt

I understand your comment. However, the issues you are raising (as  
well as others) related to 6to4 are already in the 6to4 security RFC  
(RFC3964), which is already referenced in the 6to4 paragraph.  
Therefore, I would suggest not to add any additional text in order to  
not repeat what is already throughly discussed in RFC3964.

Marc.

Le 07-08-24 à 19:41, Niall O'Reilly a écrit :

> On Thu, 2 Aug 2007 20:40:26 +0200, Gert Doering <gert@...>  
> wrote:
>> I'm coming a bit late to this (sorry)
>
> 	Apologies from me too.  At least I'm in good company. 8-)
>
> 	It would be helpful if prefixes such as 2002:a00::/24 were  
> specifically
> 	mentioned as needing special attention.  This might be done by  
> explicit
> 	mention of each such prefix.  Alternatively, language could be used
> 	which would make clear that the 6to4 image of any IPv4 block for  
> which
> 	RFC3330 specifies that "Addresses within this block should not appear
> 	on the public Internet" should be similarly avoided.
>
> 	I believe that this would be useful both to those beginning to deploy
> 	IPv6 in their networks (my case) and those running a 6to4 relay  
> service.
>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Marc Blanchet | 3 Oct 2007 15:10
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt

Gert,
  you were probably looking at the -00 version. -01 version already  
had that fix.

Marc.

Le 07-08-02 à 20:40, Gert Doering a écrit :

> Hi,
>
> I'm coming a bit late to this (sorry), but something just caught my
> eye:
>
> On Mon, Jul 23, 2007 at 12:51:28PM -0500, Marc Blanchet wrote:
>> ========
>> 2.10 is somewhat incorrect on Multicast:
>>
>>    ff00::/8 are multicast addresses [RFC4291].  They have a 4 bits
>> scope
>>    in the address field.  Only addresses having the 'E' value in the
>>    scope field are of global scope, all other values are local or
>>    reserved.  Therefore, only ffXe:: routes may be advertised  
>> outside a
>>    site, where X may be any value.
>
> I'm wondering about the word "advertised" - I've never hear anyone
> use that word in the context of multicast addresses.  They are not  
> carried
> in BGP (which is the typical "advertising" of routing data), and PIM
> isn't exactly "advertising routes".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Abley | 3 Oct 2007 16:26

Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt


On 3-Oct-2007, at 0913, Marc Blanchet wrote:

> I understand your comment. However, the issues you are raising (as  
> well as others) related to 6to4 are already in the 6to4 security  
> RFC (RFC3964), which is already referenced in the 6to4 paragraph.  
> Therefore, I would suggest not to add any additional text in order  
> to not repeat what is already throughly discussed in RFC3964.

I think readers would be well-served by a convenient, local reference  
though. If it is left to the reader to translate RFC 3330 into hex,  
chances are good that it won't happen.

How about adding some additional text to section 2.7, such as:

6to4 prefixes are constructed by embedding an IPv4 address into an  
IPv6 prefix according to [RFC3056]. Where the IPv4 address used to  
construct such a prefix is not globally-unique (or is otherwise  
reserved), the resulting 6to4 prefix is unlikely to be useful.

The following is a summary of 6to4 prefixes constructed using special- 
use IPv4 addresses, as documented in [RFC3330]. IPv4 prefixes which  
appear in [RFC3330] but which are known to have legimitate use on the  
public Internet at the time of writing are not included. Operators  
are advised to derive a policy for treatment of these 6to4 prefixes  
which is analogous to their policy for the corresponding IPv4 addresses.

   IPv4 Prefix     Description                       6to4 Prefix

   0.0.0.0/8       "this network" [RFC1700]          2002::/24
(Continue reading)

Permalink | Reply | 2 comments |
headers
Marc Blanchet | 3 Oct 2007 16:38
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt

Le 07-10-03 à 16:26, Joe Abley a écrit :

>
> On 3-Oct-2007, at 0913, Marc Blanchet wrote:
>
>> I understand your comment. However, the issues you are raising (as  
>> well as others) related to 6to4 are already in the 6to4 security  
>> RFC (RFC3964), which is already referenced in the 6to4 paragraph.  
>> Therefore, I would suggest not to add any additional text in order  
>> to not repeat what is already throughly discussed in RFC3964.
>
> I think readers would be well-served by a convenient, local  
> reference though. If it is left to the reader to translate RFC 3330  
> into hex, chances are good that it won't happen.

- but again, RFC3964 goes in depth of the rationale, implications,  
etc...
- and my understanding from previous wg discussions about this  
document is that we wanted to move out as much as possible of   
routing policy instructions.

Marc.

>
> How about adding some additional text to section 2.7, such as:
>
> 6to4 prefixes are constructed by embedding an IPv4 address into an  
> IPv6 prefix according to [RFC3056]. Where the IPv4 address used to  
> construct such a prefix is not globally-unique (or is otherwise  
> reserved), the resulting 6to4 prefix is unlikely to be useful.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Niall O'Reilly | 3 Oct 2007 17:09
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt


On 3 Oct 2007, at 14:13, Marc Blanchet wrote:

> I understand your comment. However, the issues you are raising (as  
> well as others) related to 6to4 are already in the 6to4 security  
> RFC (RFC3964), which is already referenced in the 6to4 paragraph.  
> Therefore, I would suggest not to add any additional text in order  
> to not repeat what is already throughly discussed in RFC3964.

	I understand your response, and have some sympathy with your point  
of view.

	I see two possible goals here: "communication" and "documentation".   
I'm not
	sure whether both are intended goals of the document being drafted.   
I think
	they should be.

	Repetition is a nuisance in documentation, as it involves parallel  
maintenance.
	OTOH, appropriate repetition is useful in communication, as it helps  
underline
	the message.

	My sense of the purpose of this document is that its readers ought  
to be
	adequately or even compellingly guided towards doing "the right  
thing".  What
	prompted me to comment as I did was that, in reading it, I didn't  
quite find
(Continue reading)

Permalink | Reply | 5 comments |

Gmane