Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

Hello,

I do agree with the idea in the draft and I fully support its advancement.

Lorenzo said several times, and the abstract is clear, that the 
recommendation is to not limit the number of addresses are 'provided' to 
general-purposes hosts.  I fully agree with the intent in general.

But because SLAAC is what it is, a network does not 'provide' an address 
to the host.  Worse, it is because of SLAAC universally assumed that the 
end result may look that only one address is provided to the host.

If SLAAC were not what it is, or if it were not that widely adopted, 
then the network could safely assume it 'provided' 2^64 addresses to a 
host when it set a prefixlen 64 in a RA.

For example, the draft says:
>    In most general-purpose IPv6 networks, including all 3GPP networks
>    (see [RFC6459] section 5.2) and Ethernet and Wi-Fi networks using
>    SLAAC [RFC4862], IPv6 hosts have the ability to configure additional
>    IPv6 addresses from the link prefix(es) without explicit requests to
>    the network.

YEs.  But this does not mean that it is good that a 3GPP network gives 
only one /64 to an UE.  This is not a good recommendation.

The right recommendation is the following:

"in a 3GPP network which uses exclusively SLAAC for IPv6 address
  configuration on the UE the network must not limit its ability to set
  multiple distinct IPv6 prefixes in a RA to the UE.  By default there
  should be two."

(other criteria are: in any access network which uses ptp links with 
next-hop as an address rather than a '*' in the forwarding entry for the 
general-purpose host, and exclusively SLAAC)

Also, at the following place:

OLD:
>    Example of how the availability of multiple addresses per host has
>    already allowed substantial deployment of new applications without
>    explicit requests to the network are:
[...]
>    o  /64 sharing [RFC7278].  This was a way to provide IPv6 tethering
>       without needing to wait for network operators to deploy DHCPv6 PD,
>       which is only available in 3GPP release 10.

This is not a good example either.  One wouldn't give an INFORMATIONAL 
document as a recommendation to follow.

I suggest the following NEW:

    An example of how the availability of multiple addresses per host has
    already stimulated successful new applications:
[...]
    o  tethering.  In tethering a UE such as a smartphone connects
       several IP devices on its LAN through the access network and to
       the Internet.  This is realized with DHCPv6-PD [AERO] or some
       other techniques like "/64 sharing" [RFC7278] or other forms of
       bridging.

Alex

Le 02/11/2015 14:15, Fred Baker (fred) a écrit :
> In the discussion this morning, we wound up in a position that I could not call "consensus", even "rough consensus", but per a hum of those in the room, within shouting distance of achieving that. Several people spoke at the mike asking for a sentence or brief discussion to be added, or a section clarified.
>
> In the interest of expediency, let me ask those who spoke (and anyone else that has an issue) to respond to this note (copying the list) with suggested text. It might be best if this is stated as
>
> OLD TEXT
> the text that should be replaced goes here
> NEW TEXT
> the text that should replace it goes here
>
> or
>
> LOCATION
> identify the section the text should go into
> PROPOSED TEXT
> the text that should be added goes here
>
> I'll permit the authors to declare suggested text out of scope; some of the discussion this morning left them commenting on scope and scope creep. However, I do ask them to justify the exclusion to the list, rather than just ignore the email.
>
> This comment period ends 15 November.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>