Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

[<[e-mail]>]

Hi Ole,

Thank you for the comments.

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Ole Troan [mailto:[e-mail]] 
Envoyé : jeudi 29 janvier 2015 13:15
À : Fred Baker (fred)
Cc : V6 Ops List; [e-mail]
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call


> On 28 Jan 2015, at 17:57 , Fred Baker (fred) <[e-mail]> wrote:
> 
> draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of change in the IESG. The ADs would like to see the working group read it again and comment - working group last call - before they proceed. To summarize, it provides requirements for handsets that would work in a specific business model. As such, it builds on RFC 6434 and 7066, strengthening some of those requirements, and going on to add requirements related to 464xlat and other technologies.
> 
> Please read it now, and comment. This WGLC will run until 15 February.


+1 to Lorenzo's comments.

in addition.

   C_REC#11:  If the cellular host receives the DNS information in
              several channels for the same interface, the following
              preference order must be followed:

                 1.  PCO

                 2.  RA

                 3.  DHCPv6


in the other areas this issue has come up. then the conclusion has been that the host uses all the information received. I think it would be quite unfortunate that the host stack much behave differently depending on the link-layer. I would suggest either to drop the requirement, or to say that the implementation must use all DNS servers learnt.

[Med] FWIW, this was added to have a more deterministic behavior at the cellular side. I may lost the context since early stages of the draft, but I recall there was a discussion in the list asking to make the ordering more strict: see for instance: http://www.ietf.org/mail-archive/web/v6ops/current/msg14375.html. Using all the information or follow the selection modes are two ways to achieve the same objective: determinist behavior at the terminal side. The draft recorded the feedback we received at that time.


same comment applies to W_REC#4.
[Med] There is no W_REC# in the current version. I think you are referring to W_REC#2. Same as above.

I can't see a good reason why hosts that also have cellular interfaces should work differently on a WLAN as opposed to those that don't have cellular interfaces.
[Med] The main motivation for this section was the test we have conducted on some IPv6-enabled devices that do not behave correctly when IPv6-only mode (you can see for instance what we reported here: https://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-3.3). This is an example of implementation brokenness to be avoided.


why does e.g. A_REC#3 refer to NATs?
[Med] A_REC#3 is when IPv4 service continuity is provided over IPv6. 

"Tracking a host is still possible based on the first 64
 bits of the IPv6 address.  Means to prevent against such
 tracking issues may be enabled in the network side."

what does this allude to?
[Med] All what it says is that if a host doesn't want to be tracked, changing the last 64 bits may not be sufficient.