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 protected]>
To: Arifumi Matsumoto<[email protected]>, 6man Mailing List
<[email protected]>, Brian Haberman<[email protected]>
Subject: Moving to WGLC 3484-bis?
Message-ID:
<EMEW3|12429027fc04a7f4a2ae0da321fae730n7BFLb03tjc|ecs.soton.ac.uk|[email protected]>
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
