Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

[<[e-mail]>]

Dear Mickael,

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : Mikael Abrahamsson [mailto:[e-mail]] 
>Envoyé : lundi 12 novembre 2012 09:13
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : IPv6 Ops WG
>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
>
>On Mon, 12 Nov 2012, [e-mail] wrote:
>
>> We hope this new version is ready for the WG adoption.
>
>I support adopting this as WG item, 

Med: Thanks. 

but I have some questions:
>
>In 
>"http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/09.13
>.00_60/ts_123401v091300p.pdf" 
>it says:
>
>"A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6"
>
>"If the requested PDN type is IPv4v6 and subscription data 
>only allows PDN 
>type IPv4 or only allows PDN type IPv6, the MME sets the PDN type 
>according to the subscribed value. A reason cause shall be 
>returned to the 
>UE indicating that only the assigned PDN type is allowed. In 
>this case the 
>UE shall not request another PDN connection to the same APN 
>for the other 
>IP version"
>
>So this draft is duplicating language from 3GPP spec:s, 
>correct? 

Med: Yes. 

What is 
>the rationale for the "particular" in REQ#3?

Med: We wanted to focus on the specification part which describes the behaviour for requesting IPv6-related PDP context(s). This is important to avoid having broken IPv6 implementations in cellular devices. 

 Either it's in 
>compliance or 
>it's not, right? Perhaps a short paragraph on why the 
>behaviour listed is 
>especially important?

>
>Oh, REQ5 is interesting, I never understood how traffic was 
>mapped into 
>different bearers since the QoS is done per bearer. Now I know!

Med: Great. 

>
>REQ#8: Should perhaps say GGSN/PGW intead of "GGSN" to comply 
>with 3GPP 
>language for LTE as well? (I don't understand why they changed 
>the names, 
>but they did so...)

Med: OK. BTW, we have this text in the draft:

   The requirements listed below are valid for both 3GPP GPRS and 3GPP
   EPS access.  For EPS, "PDN type" terminology is used instead of "PDP
   context".

This is why we avoided repeating both terms. 


>
>REQ#9: Hm, I am not so sure about this one. What happens if PCO and 
>RFC6106 gives different information? If DHCPv6 gives a third 
>set? Or is 
>this specified somewhere else?
>... Ah, that's in REQ#10. my bad!

Med: OK.

>
>REQ#10: Why shouldn't the host support DHCPv6 recursive DNS 
>retreival if 
>RFC6106 is supported? 

Med: This is not what the req says. The req says: 

   REQ#10:  The cellular host SHOULD embed a DHCPv6 client [RFC3736].

DHCPv6 gives more information than 
>RFC6106, I think 
>the device should support DHCPv6 regardless of RFC6106 support.

Med: The sub-requirements is only about the DNS information.

>
>REQ#11+12+13: +1 on the CLAT+NAT64+DNS64 stuff!

Med: OK.

>
>REQ#15: Is the rationale here that a device with IPv4v6 PDP 
>context will 
>get a DNS64 enabled resolver?

Med: No. The point is the host has to enforce a procedure to prefer native IPv6 connectivity. 

>
>REQ#16: It would help here to just include the text "Happy Eyeballs" 
>somewhere in the sentence, so I don't have to look at the RFC 
>to identify 
>what it is.

Med: OK. Done in my local copy.

>
>REQ#17: Should not do DAD on the PDP context interface. In case of 
>tethering/hotspot, it needs to do DAD on the wifi/lan interface, right?

Med: Yes.

>
>REQ#19: Shouldn't this be "IPv6 only"? A lot of devices today support 
>IPv4+IPv6 on wifi, but they do not consider IPv6 only as "connected". 
>Perhaps this could be clarified?

Med: Good point. BTW, we have recorded an issue similar to the one you are describing in http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-3.3. We will consider how to clarify the text.

>
>4. "these cellular devices have to meet". What does "have to" mean, is 
>that a MUST but not written as such?

Med: The normative language is used in each requirement. IMHO, no need to change "have to" to "MUST".

>
>
>This looks like an extremely useful document to have when sendning out 
>requirements to equipment vendors. Thanks!

Med: Thank you for the detailed review.