Re: [v6ops] Last Call: <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> (Unique IPv6 Prefix Per Host) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27/06/2017 01:37, Lorenzo Colitti wrote:
> Please don't cite RFC 7608. It has nothing to do with IP addressing, only
> forwarding, and the topic here is host addressing.

True. I agree that simply stating that it's currently /64 is appropriate.
The point is that /64 isn't an essential property of this solution; it's
an externally determined parameter.

   Brian

> 
> On Mon, Jun 26, 2017 at 9:12 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) <
> gunter.van_de_velde@xxxxxxxxx> wrote:
> 
>> Hi Brian,
>>
>> Thanks for the review.
>>
>> I modified the reference to /64 IPv6 prefix length and suggested instead
>> consistency with RFC7608 and that currently this likely means a /64 in the
>> -04 version.
>>
>> All the best,
>> G/
>>
>> On 26/05/2017, 22:24, "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx>
>> wrote:
>>
>>     Hi,
>>
>>     I should have noticed this during the v6ops discussions, but I didn't,
>>     sorry.
>>
>>     This draft cites RFC4862 (SLAAC) and mentions Router Advertisements
>>     (without also citing RFC4861, which is possibly a mistake). Those
>>     documents do not specify the subnet prefix length. So the draft
>>     shouldn't assume a particular prefix length either. We all know that
>>     it's usually 64 today, but that doesn't affect the argument made by
>>     the draft. We need consistency with RFC 7608 (BCP 198).
>>
>>     Regards
>>        Brian Carpenter
>>
>>     On 24/05/2017 07:41, The IESG wrote:
>>     >
>>     > The IESG has received a request from the IPv6 Operations WG (v6ops)
>>     > to consider the following document: - 'Unique IPv6 Prefix Per Host'
>>     > <draft-ietf-v6ops-unique-ipv6-prefix-per-host-03.txt> as Best
>>     > Current Practice
>>     >
>>     > The IESG plans to make a decision in the next few weeks, and
>>     > solicits final comments on this action. Please send substantive
>>     > comments to the ietf@xxxxxxxx mailing lists by 2017-06-06.
>>     > Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In
>>     > either case, please retain the beginning of the Subject line to allow
>>     > automated sorting.
>>     >
>>     > Abstract
>>     >
>>     >
>>     > In some IPv6 environments, the need has arisen for hosts to be able
>>     > to utilize a unique IPv6 prefix, even though the link or media may
>>     > be shared.  Typically hosts (subscribers) on a shared network,
>>     > either wired or wireless, such as Ethernet, WiFi, etc., will acquire
>>     > unique IPv6 addresses from a common IPv6 prefix that is allocated or
>>     > assigned for use on a specific link.
>>     >
>>     > In most deployments today, IPv6 address assignment from a single
>>     > IPv6 prefix on a shared network is done by either using IPv6
>>     > stateless address auto-configuration (SLAAC) and/or stateful DHCPv6.
>>     > While this is still viable and operates as designed, there are some
>>     > large scale environments where this concept introduces significant
>>     > performance challenges and implications, specifically related to
>>     > IPv6 router and neighbor discovery.
>>     >
>>     > This document outlines an approach utilising existing IPv6 protocols
>>     > to allow hosts to be assigned a unique IPv6 prefix (instead of a
>>     > unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
>>     > IPv6 prefix over a unique IPv6 address from the service provider
>>     > include improved subscriber isolation and enhanced subscriber
>>     > management.
>>     >
>>     >
>>     > The file can be obtained via
>>     > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv
>> 6-prefix-per-host/
>>     >
>>     >  IESG discussion can be tracked via
>>     > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv
>> 6-prefix-per-host/ballot/
>>     >
>>     >
>>     >
>>     > No IPR declarations have been submitted directly on this I-D.
>>     >
>>     >
>>     > The document contains these normative downward references. See RFC
>>     > 3967 for additional information: rfc6106: IPv6 Router Advertisement
>>     > Options for DNS Configuration (Proposed Standard - IETF stream)
>>     > rfc4941: Privacy Extensions for Stateless Address Autoconfiguration
>>     > in IPv6 (Draft Standard - IETF stream) rfc4862: IPv6 Stateless
>>     > Address Autoconfiguration (Draft Standard - IETF stream) rfc3315:
>>     > Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed
>>     > Standard - IETF stream)
>>     >
>>     >
>>     >
>>     > _______________________________________________ v6ops mailing list
>>     > v6ops@xxxxxxxx https://www.ietf.org/mailman/listinfo/v6ops .
>>     >
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]