Subject: re: Moving to WGLC 3484-bis?

From: Ray Hunter <[email-masked]>
Date: Sat, 13 Aug 2011 12:17:29 +0200

I still think there's an issue with the suggested blanket global 
treatment of IPv4 RFC1918 addresses.

Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by changing the
address scope of private IPv4 addresses to global."

IMVHO I think it is highly likely that over time this assumption will not hold true:
think end game when IPv6 native only networks are widely deployed and CGN is turned off.
At that time there's still probably going to be many (local) NAT boxes
that advertise an IPv4 default route and serve RFC1918 DHCP addresses to clients,
but cannot provide global connectivity.

So whatever you assume about RFC1918 addresses has a good chance of being incorrect
unless you can truly detect/confirm presence of global IPv4 connectivity via NAT.

I therefore suggest: "a host MAY/SHOULD attempt to determine appropriate characterization
of RFC1918 address scope (local or global) on an individual basis
e.g. via local configuration, or by connecting to a well known server on
the public Internet upon interface initiation, and asking for a reflection of
their own client IPv4 address. In the absence of further information,
a host SHOULD assume that RFC 1918 addresses are to be treated as<X>"

You can then debate whether the default<X>  should be "global" or "local".

regards,
RayH

> Message: 3
> Date: Fri, 12 Aug 2011 15:21:30 +0100
> From: Tim Chown<[email-masked]>
> To: Arifumi Matsumoto<[email-masked]>, 6man Mailing List
> 	<[email-masked]>, 	Brian Haberman<[email-masked]>
> Subject: Moving to WGLC 3484-bis?
> Message-ID:
> 	<EMEW3|12429027fc04a7f4a2ae0da321fae730[email-masked]>
> 	
> Content-Type: text/plain; charset=us-ascii
>
> Hi guys,
>
> I think we're almost ready to WGLC the 3484-bis draft, as per draft-ietf-6man-rfc3484-revise-04.
>
> We had 3 issues in Quebec:
>
> 1) Inclusion of deprecated prefixes.  It seemed the agreement in the room was to include compatibles, site-locals and 6bone prefixes in the policy table.  If that's what we do, then we need to add 3ffe::/16 back in.
>
> 2) Privacy bit indicator.  We had removed the privacy bit indicator after the heavy negative feedback in Prague to a privacy bit option for RAs, but Eric Vyncke suggested it should be added back so that an enterprise administrator could use the DHCPv6 policy distribution method to have hosts in their domain not use privacy addresses for talking to other hosts in their domain (same prefix, or ULAs).  At the moment, there is no privacy bit support.
>
> 3) Prefer greatest lifetime.  We agreed to make no change here.
>
> If we agree to add back 3ffe::/16, we could quickly produce a revise-05 and WGLC based on that, and ask in the WGLC whether there's strong support for the privacy option.  If there is, then the option bit itself would be defined in the DHCPv6 policy distribution text, and 3484-bis would need to describe the use of the bit in the updated policy table.
>
> Sound reasonable, or would a different approach be better?
>
> Tim
>
>

---

From: Philip Homburg <[email-masked]>
Date: Sat, 13 Aug 2011 14:48:17 +0200

>unless you can truly detect/confirm presence of global IPv4 connectivity via N

Ah, tricky.

For destination addresses we have 3 possibilities: v4-only, v6-only, and
dual-stack.

Obviously, without global IPv4 connectivity, connecting to v4-only destinations
is not going to work, no matter what you put in the policy table. Connecting
to v6-only destinations doesn't involve v4, so that's not an issue either.

For dual stack, connecting over v6 is preferred unless one v6 address is 
6to4 or teredo. Given that you are unlikely to have 6to4 or teredo in
that kind of environment, that's not going to be the local address.

So there is one remaining corner case. If the remote address is 6to4 or
teredo, then the policy table will prefer IPv4.

I'm not sure it's worth making thing more complex just o handle this corner
case.