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

[Ray Hunter <[e-mail]>]

> Jouni <mailto:[e-mail]>
> 14 May 2013 00:30
> Ray,
>
> Thanks for putting effort to read the document. Some initial comments inline.
>
> On May 14, 2013, at 1:00 AM, Ray Hunter wrote:
>
>> 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.
>
> Reason being quite simple. When describing what a 3GPP UE can do, we cannot
> 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
> stuff that would make sense but not really anything beyond that. And we
> have tried to be pedantic on that.
I'll hold you to 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.

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."



>> 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.
>
> 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.
>
>> 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.
>
> The original RFC3316 still gets referenced and that somewhat needed a
> 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
> 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
>
>
>> regards,
>> RayH
>>
>> Fred Baker (fred) wrote:
>>> 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
>>>
>>>
>>>
>>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>