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

["Brzozowski, John" <[e-mail]>]

Tore apologies, I thought I/we replied to all comments that required a
reply.  We have all the feedback and will factor in as part of our update.
 See below for more.

John
[phone]




-----Original Message-----
From: v6ops <[e-mail]> on behalf of Tore Anderson
<[e-mail]>
Date: Monday, January 4, 2016 at 07:41
To: Fred Baker <[e-mail]>
Cc: v6ops <[e-mail]>
Subject: Re: [v6ops] Focused discussion:
draft-ietf-v6ops-unique-ipv6-prefix-per-host

>* [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.
[jjmb] I respectfully disagree, I have built a very large IPv6 deployment
based on this.  Experience tells me it works.  I (Comcast hat on) will
continue to use these bit in this manner.
>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.
[jjmb] lots of discussion that I read and largely disagreed with, see
comment above.   This ship has sailed, we all must now agree to disagree.
Let’s not start another tidal wave of emails on this topic.
>
>  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.)
[jjmb] I currently have no intention of removing reference to M/O bit = 1
and the use of stateful DHCPv6 for PD.  This is how the same will be
deployed, the document will reflect reality.  If I misunderstood your
comments I apologize.
>
>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.
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops