Re: [v6ops] Focused discussion: draft-ietf-v6ops-unique-ipv6-prefix-per-host

[Tore Anderson <[e-mail]>]

* [e-mail]

> And now for something a little different. I'd like to invite focused
> discussion of draft-ietf-v6ops-unique-ipv6-prefix-per-host, which we
> adopted at IETF 94

FWIW, I sent some feedback to the list on the 28th of October, which
wasn't answered* or incorporated in the new revision of the draft as far
as I can tell. I'll therefore repeat them below.

* Except for point #2 regarding the draft improperly suggesting that
  when IA_PD is available the M-flag should be set to 1. This did cause
  some discussion on whether or not RA flags have any relation to IA_PD
  availability to begin with, but I don't think there was any
  disagreement about my initial point about tying IA_PD with the M-flag
  specifically not being appropriate.

  Easiest way to fix this in the draft is IMHO just to remove «, this
  flag may be set to 1 in the future if/when DHCPv6 prefix this flag
  may be set to 1 in the future if/when DHCPv6 prefix)». (Just noticed
  this will also get rid of an unmatched parenthesis.)

Tore

------

1) Section 4.2 mentions that DAD is used, but it is not clear to me how
this will work for LLAs. If two UEs (potentially attached to different
APs) are using the same link-local address, how will they see each
others DAD messages? Proxy-ND on the WLAN-GW? Or if the WLAN-GW does
not relay DAD messages across the split BUM horizon, how will it deal
with the possiblity of two unique UEs both using the same LLA? I'm
guessing that in a large-scale deployment, the chances of two UEs
having statically configured, e.g., fe80::1 is quite likely.

2) Regarding the following text in Section 4.2:

>   o  M-flag = 0 (UE/subscriber address is not managed through DHCPv6),
>      this flag may be set to 1 in the future if/when DHCPv6 prefix
>      delegation support over Wi-Fi is desired)  

As I understand it (and I do stress that), the M-flag indicates whether
or not *addresses* are available via DHCPv6 (RFC 4861 s4.2). Prefixes
(IA_PD) is something different. Therefore, assuming that availability of
IA_PD is signalled using RA flags to begin with, then it is "other
configuration" and thus signalled with the O-flag, not the M-flag. I
know of at least one wireline ISP that has such a deployment, i.e.,
they support DHCPv6 IA_PD but not IA_NA/IA_TA, and they signal this
using M=0 + O=1.

3) The draft describes tunneling traffic in a stateless manner. I take
that to mean that the APs and WLAN-GW will be incapable of performing
reassembly at tunnel egress (and by extension that they won't fragment
GRE packets on ingress either). That in turn means that you either 1)
need to allow for jumbo frames in the transport network between the
WLAN-GW and the APs, or 2) provide UEs with a reduced MTU (which
implies the RA MTU option should be used and possibly also TCP-MSS
clamping at the WLAN-GW). Since this is an operational guidance
document I believe this is something that should be discussed.

4) Is UE roaming between APs/BSSIDs supported, and if so how does this
work? As I understand it, the WLAN-GW will have 1 GRE interface per AP,
so if a UE roams from one AP to another, its MAC address and all of its
associated IPv6 addresses will (from the WLAN-GW's POV) move from one
GRE interface to another, which would in turn require the WLAN-GW to
somehow notice this and move the associated /64 and any NDP entries
from the previous GRE interface to the current one. Right? If so, some
discussion on how that happens would be appreciated (or at least a
statement that "secret vendor sauce is assumed to be applied here" if
that is indeed the case).

5) This is just a thought, but regarding the operational consideration
in section 5 regarding supporting privacy addresses: Would it be
possible for the WLAN-GW to simply send all traffic destined for the
UE's dedicated /64 to the UE's MAC address without maintaining ND
entries for each address in use? This way, a single UE could use
gazillions of IPv6 addresses without risking resource exhaustion in the
WLAN-GW. OTOH, maybe that would cause problems for UEs that are
providing tethering to downstream hosts using layer-2 bridging?

6) Some editorial nits I noticed (although I wasn't specifically
looking for them): Missing «.» at the end of page 7, s/Lawfull/Lawful/
on page 12.