Subject: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 12 May 2013 20:00:17 +0000

This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-ietf-v6ops-rfc3316bis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make

draft-ietf-v6ops-rfc3316bis idnits

---

From: Ray Hunter <[email-masked]>
Date: Tue, 14 May 2013 00:00:38 +0200

I have read this document. I cant say that I support it.

IMHO it's too time specific and too version specific, without proving
added value and general guidance.

On the one hand there are requirements to implement a kludge to cope
with historical limitations in mobile networks and the fact the gateway
could only handle a single prefix route (RFC6603), whereas every other
network I know of easily handles numbering of the link "to the site"
without this.

On the other hand there isn't a requirement for something really basic
in the IPv6 vision, like BCP 157, so that a device can always be
provided with enough addresses/prefixes to properly number all of its
interfaces using SLAAC without resorting to workarounds like
draft-ietf-v6ops-64share-04.

I therefore question what this document adds above and beyond reading
the detailed 3gpp version releases/ specs, and why the IETF should
publish this document at all.

regards,
RayH

---

From: Jouni <[email-masked]>
Date: Tue, 14 May 2013 01:30:54 +0300

Ray,

Thanks for putting effort to read the document. Some initial comments inline.

> added value and general guidance.

Reason being quite simple. When describing what a 3GPP UE can do, we cannot
really go beyond what has been specified so far. We can point out some
stuff that would make sense but not really anything beyond that. And we
have tried to be pedantic on that.

I somewhat disagree about the lack general guidance. Experience has shown
that it usually takes real effort explaining some of the weird details of
the 3GPP link and how corners have been cut there. Take the NDP details
as an example.

> draft-ietf-v6ops-64share-04.

Something we have to live with at the moment. RFC3314 tried to recommend
otherwise but what was recommend did not materialize. Even if I really
wanted to recommend support for multiple prefixes on a 3GPP link, this
document is not a recommendation document but what has to be there for
an IPv6 enabled UE.

> publish this document at all.

The original RFC3316 still gets referenced and that somewhat needed a
facelift. Mostly because when RFC3316 came out we did not even have
the node requirements document, and a lot of stuff that really belongs
to the node requirements document is duplicated (and now outdated) in
RFC3316.

- Jouni

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ray Hunter <[email-masked]>
Date: Tue, 14 May 2013 08:55:02 +0200

> Jouni <mailto:[email-masked]>
> 14 May 2013 00:30
> Ray,
>
> really go beyond what has been specified so far.
>
Right. And that's my basic problem with the IETF producing such a document.
>  We can point out some
I'll hold you to that ;)
> the 3GPP link and how corners have been cut there. Take the NDP details

Right. But then I humbly suggest that the document just covers the
"weird details".

Forgive my apparent frustration. In my very simple mind, 3gpp "blew it
big time" at the architecture level.

Quote "If a cellular host has additional interfaces on which IP is used,
   (such as Ethernet, WLAN, Bluetooth, etc.) then there may be
   additional requirements for the device, beyond what is discussed in
   this document."

The starting point for 3gpp in the IETF should have been how to
transport packets over the basic link technology, and then looking at
how the ecosystem of end user devices an individual owned could
collectively connect to the Internet, rather than the end user device
being relegated to nothing more than a dedicated handset on the end of a
single radio link with no alternate paths.

Following comments from "my very simple mind," which might equate to how
some developers will read this document.
Please forgive me /indulge me, as I feel it will improve the quality of
the draft.

We're basically talking about a dedicated point to point link between a
piece of provider equipment (GGSN/PGW) and a piece of consumer equipment
(TE).

Quote draft-ietf-v6ops-rfc3316bis:
"The Router Advertisement contains a maximum
   of one prefix information option and the advertised prefix cannot
   ever be used for on-link determination (see [RFC6459], Section 5.2)."

Quote RFC4862:
Router Advertisements also contain zero or more Prefix Information
   options that contain information used by stateless address
   autoconfiguration to generate global addresses.

What breaks if an end device supports receiving more than one PIO in an RA?

Advising implementers of cellular hosts to box themselves into a corner
based on the current implementation of the network equipment would seem
to me to be a bad idea if it isn't absolutely necessary.

Section 2.6. "Consequently, sending MLD reports for link-local addresses
in a 3GPP environment may not always be necessary"

What does this tell me as a developer? How do I discover this?
Is it harmful to never send MLD? Is it harmful to always send MLD?
That I need to try once and see if sending MLD is necessary (to avoid
unnecessary 3gpp traffic)?

Section 2.7
What has RFC 4941 got to do with 3gpp link technology and corner cases?

6459 says "RFC 4941 or other similar types of mechanisms."
draft-ietf-v6ops-rfc3316bis says "Privacy Extensions for Stateless
Address Autoconfiguration [RFC4941] should be supported."

What breaks if other privacy mechanisms are used, so that
draft-ietf-v6ops-rfc3316bis has been sharpened to SHOULD support 4941?
Or none?

Quote "At the time this document has been written, there is no
experience on how long-lived cellular network address assignments (i.e.,
attachments to the network) are. "

Again, what is this draft telling me as a developer?

Section 2.9 Is this kludge forever?
What is fundamentally wrong in the long term with unnumbered links?
What is fundamentally wrong in the long term with the radio provider
using their own IPv6 space for the radio link, and delegating an entire
contiguous block to the user to allocate.

(which is what the majority of other IP networks do AFAIK).

Section 2,10

"The cellular host should implement the Default Router Preferences and
More-Specific Routes extension to extension to Router Advertisement
   messages [RFC4191]. These options me be useful for cellular hosts
that also have additional interfaces on which IPv6 is used."

Wasn't this specifically declared out of scope in Section 1.1? "If a
cellular host has additional interfaces on which IP is used, (such as
Ethernet, WLAN, Bluetooth, etc.) then there may be additional
requirements for the device, beyond what is discussed in this document."

> facelift.

Quote draft-ietf-v6ops-rfc3316bis: "Future changes in 3GPP networks that
impact host implementations may result in updates to this document."

I don't see the fact that RFC3316 is still referenced as a reason to
repeat the same mistake of having a specific IETF document that needs to
then somehow synchronise with the work of another standards body that
operates completely outside the IETF's scope of influence.

Thanks for your patience,
RayH
>  Mostly because when RFC3316 came out we did not even have

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 15 May 2013 10:59:04 +0300

RAy,

> What breaks if an end device supports receiving more than one PIO in an RA?

Probably nothing. There just are no gateways that would put more than one
PIO in an RA.

The language is there just because 3GPP specs are explicit on stating it 
as a restriction to SLAAC.

> to me to be a bad idea if it isn't absolutely necessary.

Well.. I do not disagree here :)

> unnecessary 3gpp traffic)?

Right. I could say "Consequently, sending MLD reports for link-local
addresses in a 3GPP environment is not necessary" That would be more
explicit?

> draft-ietf-v6ops-rfc3316bis has been sharpened to SHOULD support 4941?

Right. I can reword this similar to RFC6459. 

> Section 2.9 Is this kludge forever?

Dunno.

> What is fundamentally wrong in the long term with unnumbered links?

Nothing. It is just not an option with 3GPP link model (and do not refer
here to 64share that shows what one do with a host implementation).

> contiguous block to the user to allocate.

Nothing. 

Just to point out that "we tried we failed". I am actually happy that
we even got DHCPv6 PD into specs instead of something more "ingenious".

> requirements for the device, beyond what is discussed in this document."

Right. So you want that removed?

- JOuni

---

From: Owen DeLong <[email-masked]>
Date: Wed, 15 May 2013 10:13:54 -0700

> as a restriction to SLAAC.

It's kind of a dumb restriction IMHO. I don't think it is valuable to bring dumb
restrictions from 3GPP over to IETF unless it is necessary to avoid incompatibility.

> Well.. I do not disagree here :)
+1

> addresses in a 3GPP environment is not necessary" That would be more

It would be more explicit. Would it be correct? If so, then it should be stated this way.

> Right. So you want that removed?

I don't support removal. If anything, I would suggest that more explicit information
about the various scenarios and their considerations is required. If not in this
document, then somewhere else that is referenced by this document.

Instead, I think an update to 1.1 mentioning that the treatment in 2.10 is not
complete rather than out of scope might be worth while.

Owen

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 16 May 2013 10:35:34 +0300

> restrictions from 3GPP over to IETF unless it is necessary to avoid incompatibility.

I don't disagree about the "dumbness".. However, that is a restriction of the 
link itself and buried pretty deep in the architecture. So, if the UE receives
an RA with multiple PIOs a) someone is goofing around or b) the network side
is broken. In that regard, I would still like to keep some text around this
peculiarity in the document. Would it be acceptable to state the fact and say
something along the lines that changing the UE stack implementation to meet
this link requirement is not really needed?

- Jouni

---

From: Ray Hunter <[email-masked]>
Date: Thu, 16 May 2013 12:31:29 +0200

> Jouni Korhonen <mailto:[email-masked]>
> 16 May 2013 09:35
>
> ------------------------------------------------------------------------
IMHO This is symptomatic of the poor relationship between IETF standards
and 3gpp standards. 3gpp has limited something gratuitously that wasn't
limited in the referenced IETF standard. And it didn't need limiting at
standards level anyway: it's a network equipment end implementation
decision. It may be buried in the 3gpp architecture, but it's certainly
NOT buried deep in the IETF architecture.

So you could indeed mention that current versions of 3gpp network
equipment send exactly one PIO, but IMHO the IETF standard should be
kept as intended and unmodified: the TE should accept zero or more PIO
options. Unless it truly breaks something in 3gpp. That way you have
guaranteed interop with 3gpp, without limiting flexibility, or having to
implement unnecessary changes to existing generic running code on a
device that runs IPv6 and also happens to be a 3gpp TE. This is basic
Postel's law.

Futher I cross checked draft-ietf-v6ops-rfc3316bis against rfc6459 (IPv6
in 3rd Generation Partnership Project)
I'm certainly not an expert in this field (just another dumb reader),
but I do like to read consistent and maintainable standards.

AFAICS & IMVHO
Section 2.1 doesn't tell me anything that isn't obvious.
Section 2.2 is mostly covered in rfc6459 section 5.4. Only new material
is regarding [RFC4861], Section 7.3.1, but again that should be pretty
obvious to stack implementers, or could simply be a reference.
Section 2.3 is covered in rfc6459 section 5.2
Section 2.4 is covered in rfc6459 section 5.2
Section 2.5 looks like new information to me and provides actionable advice.
Section 2.6 looks like new information to me but does not tell me any
actionable advice.
Section 2.7 has nothing to do specifically with 3gpp links and could be
better handled elsewhere as a generic IPv6 privacy issue as AFAICS there
are no interop issues specific to 3gpp, and no need to quote 4941
specifically.
Section 2.8 is covered in rfc6459 section 5.2
Section 2.9 is covered in rfc6459 section 5.3
Section 2.10 looks like new information to me, but only contains partial
advice on handling multiple interfaces, so it could do with fleshing
out, or removal [I have no strong opinion either way]
Section 2.11looks like new information regarding handling the MTU option
and looks actionable
Section 3 looks redundant or incomplete.
Section 4 is redundant: an end node may still want to support mobile
IPv6 for e.g. wifi or other purposes: end nodes are not just TE's.

So in summary: I'm seeing an awful lot of unnecessary
duplication/overlap of text with an existing RFC that could be simply
referenced as a whole, and the areas that are providing new information
to me seem to require either more fleshing out, or additional actionable
advice.

I hope you can do something positive with this critique from a dumb reader.

Security considerations
quote "In some cases, users are billed according to the amount of data
they transfer to and from their host.  It is crucial for both the
network and the users that the airtime is used correctly and no extra
charges are applied to users due to misbehaving third parties."

<rant>This is not a technical issue, and the criticism is not directed
at the authors, but I find this outrageous. Why do end users have to pay
for control traffic that doesn't directly benefit them or provide them a
service they've requested? Users don't pay for call set up traffic on
the voice bearers until the call is actually established and answered.
Nor do they pay for maintaining time or other network management
information like establishing network credentials and cell hand off. So
why does the IETF have to put in place a load of technical kludges at
the IPv6 layer to cover something that is fundamentally a billing issue?
If the providers just didn't bill for traffic with a destination address
of the internal network control devices, there'd be no need for any of
this.</rant>

best regards,
RayH

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 16 May 2013 19:08:42 +0000

> this link requirement is not really needed?

</chair>
>From my perspective, it sounds like a good idea. Making the UE accept multiple prefixes even if they will not be sent is simply robust software design. Imagine that someone sent a n RA with two PIOs (pick your reason that might happen - maybe it's a trial or something). Making a software change on the UE that caused it to not understand the information element could cause one of several kinds of failure. I'd suggest that the document recommend that the UE be robust to the potential event.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 17 May 2013 13:40:16 +0300

Btw.. The upcoming draft version -03 and its changes can be tracked 
in Github: https://github.com/jounikor/draft-ietf-v6ops-rfc3316bis

- Jouni