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

From: <[email-masked]>
Date: Mon, 12 Nov 2012 07:47:48 +0100

Dear all,

As discussed in the v6ops meeting, we re-submitted a new version of the text which does not update RFC3316.

We hope this new version is ready for the WG adoption.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 12 novembre 2012 07:42
À : [email-masked]
Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Internet Protocol Version 6 (IPv6) Requirements for Cellular Hosts
	Author(s)       : David Binet
                          Mohamed Boucadair
                          Ales Vizdal
                          Cameron Byrne
                          Gang Chen
	Filename        : draft-binet-v6ops-cellular-host-requirements-00.txt
	Pages           : 15
	Date            : 2012-11-11

Abstract:
   This document lists a set of IPv6-related requirements to be
   supported by cellular hosts.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-requirements-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 12 Nov 2012 09:12:53 +0100 (CET)

> We hope this new version is ready for the WG adoption.

I support adopting this as WG item, 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? What is 
the rationale for the "particular" in REQ#3? 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!

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

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!

REQ#10: Why shouldn't the host support DHCPv6 recursive DNS retreival if 
RFC6106 is supported? DHCPv6 gives more information than RFC6106, I think 
the device should support DHCPv6 regardless of RFC6106 support.

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

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

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.

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?

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?

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

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

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Mon, 12 Nov 2012 10:18:34 +0100

Dear Mickael,

Please see inline. 

Cheers,
Med 

>De : Mikael Abrahamsson [mailto:[email-masked]] 
>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
>
>I support adopting this as WG item, 

Med: Thanks. 

but I have some questions:
>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 

>different bearers since the QoS is done per bearer. Now I know!

Med: Great. 

>language for LTE as well? (I don't understand why they changed 

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. 

>... Ah, that's in REQ#10. my bad!

Med: OK.

>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 

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

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

Med: OK.

>get a DNS64 enabled resolver?

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

>somewhere in the sentence, so I don't have to look at the RFC 

Med: OK. Done in my local copy.

>tethering/hotspot, it needs to do DAD on the wifi/lan interface, right?

Med: Yes.

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

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

>requirements to equipment vendors. Thanks!

Med: Thank you for the detailed review.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 12 Nov 2012 10:52:17 +0100 (CET)

On Mon, 12 Nov 2012, [email-masked] wrote:

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

Perhaps text could be included in the document about this, it's included 
for some other requirements.

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

I think REQ#15 should be re-written.

REQ#15: The cellular host SHOULD, when dual stacked, support means to 
prefer native IPv6 connection when faced with possibility of native IPv6, 
NAT64 or NAT44 connection to the same destination.

... or something to that effect. The find the current wording confusing.

>> tethering/hotspot, it needs to do DAD on the wifi/lan interface, right?

Clarification in the text?

---

From: <[email-masked]>
Date: Mon, 12 Nov 2012 11:17:55 +0100

Re-,

Please see inline.

Cheers,
Med 

>Envoyé : lundi 12 novembre 2012 10:52
>Objet : RE: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt
>

Med: I added this to my local copy:

        The text above focuses on the specification part which explains
        the behavior for requesting IPv6-related PDP context(s).
        Understanding this behavior is important to avoid having broken
        IPv6 implementations in cellular devices.

Do we need to say more?

>Perhaps this could be clarified?

Med: I updated the text as follows:

OLD:

             If [RFC6106] is not supported, the cellular host SHOULD
             retrieve DNS information using stateless DHCPv6 [RFC3736].

NEW:

             If [RFC6106] is not supported, the cellular host SHOULD
             retrieve DNS information using stateless DHCPv6 [RFC3736].
             Note stateless DHCPv6 is useful to retrieve other
             information than DNS.

>... or something to that effect. The find the current wording 

Med: I updated the text as follows:

OLD:

   REQ#15:  The cellular host SHOULD support means to prefer native IPv6
        connection over NAT64 devices or NAT44 when the cellular host
        gets dual stack connectivity.

NEW:

   REQ#15:  When the cellular host is dual stack connected, it SHOULD
        support means to prefer native IPv6 connection over NAT64
        devices or NAT44.

Better?

>Clarification in the text?

Med: I updated the text as follows:

OLD:

   REQ#17:  The cellular host SHOULD NOT perform Duplicate Address
        Detection (DAD) for these Global IPv6 addresses (as the GGSN or
        PDN-GW must not configure any IPv6 addresses using the prefix
        allocated to the cellular host).

NEW:

   REQ#17:  The cellular host SHOULD NOT perform Duplicate Address
        Detection (DAD) for these Global IPv6 addresses (as the GGSN or
        PDN-GW must not configure any IPv6 addresses using the prefix
        allocated to the cellular host).  Refer to Section 4 for DAD
        considerations on the LAN interface when the 3GPP connection is
        shared.

Are you Ok with the new text?

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 13 Nov 2012 14:36:34 -0600

I support the adoption.

Regards,

Behcet

On Mon, Nov 12, 2012 at 12:47 AM,  <[email-masked]> wrote:
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tore Anderson <[email-masked]>
Date: Thu, 15 Nov 2012 16:12:10 +0100

Hi,

REQ#8 («the cellular host MUST use the interface identifier sent in PDP
Context Accept message to configure its link local address») is rather
tricky to implement for a cellular dongle that emulate an Ethernet
device (such as an USB CDC Ethernet class device). In that case, the
dongle provides an invented Ethernet MAC address from which the host
derives an link local address using EUI-64.

Since this link local address does not have the correct interface
identifier, ND may (partially) break. In particular, I've experienced
that when sending an RS from such an EUI-64-derived link local address
to the network, the GGSN reponds with an RA that is unicasted to the
link local address the network expects the hosts to have. The host has
no knowledge of this address, and discards the RA.

I don't have a good answer to how this problem should be solved.
However, if the document could make some recommendations (or at least
describe the problem), that would be good.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

---

From: <[email-masked]>
Date: Thu, 15 Nov 2012 17:04:59 +0100

Hi,

It seems it is an implementation issue.
REQ#8 mandates the use of Interface Identifier sent by the Gateway to configure the link local address and actually it is consistent with 3GPP specification. 
We have integrated in last version of the draft some other implementation issue we may have on Wi-Fi interface (report to REQ#19).  
Please provide some text if you want to describe some implementation issues you have identified.  

Best Regards
David

> De : [email-masked] [mailto:[email-masked]] 
> De la part de Tore Anderson
> Envoyé : jeudi 15 novembre 2012 16:12
> Objet : Re: [v6ops] 
> draft-binet-v6ops-cellular-host-requirements-00.txt
> 
> Hi,
> 
> REQ#8 («the cellular host MUST use the interface identifier 
> sent in PDP Context Accept message to configure its link 
> local address») is rather tricky to implement for a cellular 
> dongle that emulate an Ethernet device (such as an USB CDC 
> Ethernet class device). In that case, the dongle provides an 
> invented Ethernet MAC address from which the host derives an 
> link local address using EUI-64.
> 
> Since this link local address does not have the correct 
> interface identifier, ND may (partially) break. In 
> particular, I've experienced that when sending an RS from 
> such an EUI-64-derived link local address to the network, the 
> GGSN reponds with an RA that is unicasted to the link local 
> address the network expects the hosts to have. The host has 
> However, if the document could make some recommendations (or 
> at least describe the problem), that would be good.
> 
> Best regards,
> --
> Tore Anderson
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jouni <[email-masked]>
Date: Thu, 15 Nov 2012 23:35:46 +0200

Hi,

> derives an link local address using EUI-64.

And usually you also get other weird stuff along this like the stack
thinking the link really is ethernet and thus requiring address resolution
to work.. which itself is bogus as the 3GPP link has no link-layer
addresses.

> no knowledge of this address, and discards the RA.

Yep. But I say here the UE is more wrong than the gateway since the 3GPP
link definition says the gateway _tells_ the UE the IID to use with the
link-local.

> describe the problem), that would be good.

Simple. Get USB class fixed.

- Jouni

---

From: <[email-masked]>
Date: Fri, 16 Nov 2012 12:59:45 +0100

Dear Tore,

This is indeed a problem which is encountered with several implementations (both USB dongles and smartphones). My colleague Olivier (cced) reported to me  four implementations are behaving as you described in your message.

This is an implementation issue. We can add a note about these implementation but the recommendation is still: be compliant with REQ#8.

Cheers,
Med

>De : Tore Anderson [mailto:[email-masked]]

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Nov 2012 17:39:28 +0900

I do not think this document is ready for WG adoption.

To start with, I see a few general issues.

First, the document is attempting to standardize behaviours that are
already standardized by 3GPP. This is leads to many of the requirements
being redundant because they are already included in 3GPP specs. If the
manufacturer is violating those specs already, I doubt that an RFC that
says "don't violate those specs" is going to have any effect at all. This
also presents the problem that if the 3GPP standards are updated, the text
becomes out of date.

Second, most of this document attempts to standardize feature sets, not
protocols or interoperability. I'm not sure this is is in scope for the
IETF, and even more so for an operations group inside the IETF.

Third, IETF work is supposed to proceed in parallel with running code, not
in the absence of running code. I very doubt there are two interoperable
implementations that satisfy all these requirements (actually, I doubt that
any real implementation satisfies even half of them). Attempting to specify
these requirements will not change that.

Moving on, at least these requirements are redundant and should be removed
or replaced by a reference to the appropriate specs:

REQ#3: Redundant with 3GPP specs.
REQ#4: Redundant with 3GPP specs.
REQ#5: Redundant with 3GPP specs.
REQ#6: Redundant with IPv6 node requirements.
REQ#7: Redundant with IPv6 node requirements.
REQ#7: Redundant with IPv6 node requirements and 3GPP specs.
REQ#15: Redundant with RFC 6724.
REQ#17: Redundant with 3GPP specs.

A few specific comments as well:

REQ#1: why do you need to cite RFC 5952? It has nothing to do with
connecting to cellular networks, and it's already in RFC 6434 (IPv6 Node
Requirements).

REQ#10: Not clear what happens if more than one provisioning method
provides DNS. Should the phone just information from one of them? Or should
it list all of them in priority order?

REQ#11: Not clear to me what this means. I understand the "implement the
NAT64 discovery heuristic" requirement, but not the part that references
RFC 6052. What does the host need to implement from RFC 6052?

REQ#18: Meaningless. Saying "MAY" in a requirements document is no better
than saying nothing.

REQ#25: What is the point of supporting RFC 5175 if it defines no new flags?

REQ#27: Why support DHCPv6 PD if no mobile networks will support it for a
number of years?

REQ#28: Duplicate of #12.

On Sun, Nov 11, 2012 at 10:47 PM, <[email-masked]> wrote:

>         Filename        :
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories:
> http://www.ietf.org/shadow.html

---

From: <[email-masked]>
Date: Mon, 19 Nov 2012 10:57:01 +0100

Hi,

Some answers inline

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Lorenzo Colitti
Envoyé : lundi 19 novembre 2012 09:39
À : BOUCADAIR Mohamed OLNC/OLN
Cc : IPv6 Ops WG
Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

First, the document is attempting to standardize behaviours that are already standardized by 3GPP. This is leads to many of the requirements being redundant because they are already included in 3GPP specs. If the manufacturer is violating those specs already, I doubt that an RFC that says "don't violate those specs" is going to have any effect at all. This also presents the problem that if the 3GPP standards are updated, the text becomes out of date.
[[david]] The goal of this document as indicated in several messages is to get a document where all IPv6 specifications for a mobile terminal are present. Actually it happens quite often that IETF documents have to be updated because of standards modifications and it is even the case for RFC3316.
And I do not understand the comment about the need to remove some requirements and to provide a link to RFC3316bis document. I do not understand why a RFCbis draft was proposed if the specifications were already present in draft-binet-* document.

Second, most of this document attempts to standardize feature sets, not protocols or interoperability. I'm not sure this is is in scope for the IETF, and even more so for an operations group inside the IETF.
[[david]] It is your opinion but as operator, it is something which is very important and there is a lack in standardisation documents where some IPv6 profile is defined. We receive a lot of support about such specifications.

Third, IETF work is supposed to proceed in parallel with running code, not in the absence of running code. I very doubt there are two interoperable implementations that satisfy all these requirements (actually, I doubt that any real implementation satisfies even half of them). Attempting to specify these requirements will not change that.
[[david]] You are right and we can imagine there is no implementation because there are no clear specifications and it is the gap we are trying to fill thanks to this document. If this document becomes a working group document, it amy be a first step in the process to get more and more IPv6 terminals and to lead some interoperable implementations. At this stage, the goal is to consider this document as a working group document. I think we can discuss about your specific comments below (even if I provided a global comment about some of them upper in the mail) when the document will be considered as a working group document.

Moving on, at least these requirements are redundant and should be removed or replaced by a reference to the appropriate specs:

REQ#1: why do you need to cite RFC 5952? It has nothing to do with connecting to cellular networks, and it's already in RFC 6434 (IPv6 Node Requirements).

REQ#10: Not clear what happens if more than one provisioning method provides DNS. Should the phone just information from one of them? Or should it list all of them in priority order?

REQ#11: Not clear to me what this means. I understand the "implement the NAT64 discovery heuristic" requirement, but not the part that references RFC 6052. What does the host need to implement from RFC 6052?

REQ#18: Meaningless. Saying "MAY" in a requirements document is no better than saying nothing.

REQ#27: Why support DHCPv6 PD if no mobile networks will support it for a number of years?

On Sun, Nov 11, 2012 at 10:47 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi 12 novembre 2012 07:42
À : [email-masked]<mailto:[email-masked]>
Objet : I-D Action: draft-binet-v6ops-cellular-host-requirements-00.txt

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Nov 2012 19:03:18 +0900

On Mon, Nov 19, 2012 at 6:57 PM, <[email-masked]> wrote:

> **
>
> And I do not understand the comment about the need to remove some
> requirements and to provide a link to RFC3316bis document. I do not
> understand why a RFCbis draft was proposed if the specifications were
> already present in draft-binet-* document.
>
> Because that draft properly updates RFC3316. This document does not update
RFC3316, it's something completely different.

> [[david]] It is your opinion but as operator, it is something which is
> very important and there is a lack in standardisation documents where some
> IPv6 profile is defined. We receive a lot of support about
> such specifications.
>
> Does the IETF define an IPv4 profile? If not, why not?

---

From: <[email-masked]>
Date: Mon, 19 Nov 2012 11:30:45 +0100

________________________________
De : Lorenzo Colitti [mailto:[email-masked]]
Envoyé : lundi 19 novembre 2012 11:03
À : BINET David OLNC/OLN
Cc : BOUCADAIR Mohamed OLNC/OLN; IPv6 Ops WG
Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

On Mon, Nov 19, 2012 at 6:57 PM, <[email-masked]<mailto:[email-masked]>> wrote:
And I do not understand the comment about the need to remove some requirements and to provide a link to RFC3316bis document. I do not understand why a RFCbis draft was proposed if the specifications were already present in draft-binet-* document.
Because that draft properly updates RFC3316. This document does not update RFC3316, it's something completely different.
[[david]] You are right. It is different and the goal is to get a document where we can have all IPv6 specifications.
Besides, I do not have the feeling that there was some demand for a RFC3316 update whereas there was some support for a document providing an IPv6 profile, as proposed in draft-binet-.
Second, most of this document attempts to standardize feature sets, not protocols or interoperability. I'm not sure this is is in scope for the IETF, and even more so for an operations group inside the IETF.
[[david]] It is your opinion but as operator, it is something which is very important and there is a lack in standardisation documents where some IPv6 profile is defined. We receive a lot of support about such specifications.
Does the IETF define an IPv4 profile? If not, why not?
[[david]] As an operator, I would say such document would not be required if we had IPv6 terminals. But it is not the case and we need to get such reference even if it is not our only action to get such devices.
Does the IETF define an IPv6 profile for CPE ? Yes. Now, there is RFC6204.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 19 Nov 2012 19:40:17 +0900

On Mon, Nov 19, 2012 at 7:30 PM, <[email-masked]> wrote:

> **
>
> Besides, I do not have the feeling that there was some demand for a
> RFC3316 update whereas there was some support for a document providing an
> IPv6 profile, as proposed in draft-binet-.
>
> Strange. I had the opposite feeling.

>> [[david]] As an operator, I would say such document would not be required
> if we had IPv6 terminals. But it is not the case and we need to get such
> reference even if it is not our only action to get such devices.
>
> Actually, we do have IPv6 terminals. Verizon Wireless has shipped tens of
millions of them.

---

From: <[email-masked]>
Date: Mon, 19 Nov 2012 13:11:51 +0100

Dear Lorenzo,

Since we first submitted draft-binet-*, which says explicitly it is intended to update rfc3316,  no one complained in the mailing list about the structure of the draft to follow rfc3316 structure but instead there were constructive technical discussions to clarify several of the requirements, to propose new ones, etc. There were several voices to support this effort.

We are happy to see draft-binet-* revived the discussion about rfc3316 update and helped authors of draft-jouni-* to publish their document...

We didn't adopted rfc3316 structure because we wanted a comprehensive list of IPv6 features required to have acceptable IPv6 implementations which can be connected to a cellular network.

There are several IPv6 implementations but some of these implementations are broken (e.g., see the issue raised by Tore in this thread). We hope draft-binet-* will help in this area.

The rationale adopted in draft-binet-* is not new to v6ops...similar effort was carried out to define the CPE profile.

Cheers,
Med

Envoyé : lundi 19 novembre 2012 11:40

On Mon, Nov 19, 2012 at 7:30 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Besides, I do not have the feeling that there was some demand for a RFC3316 update whereas there was some support for a document providing an IPv6 profile, as proposed in draft-binet-.
Strange. I had the opposite feeling.
Does the IETF define an IPv4 profile? If not, why not?
[[david]] As an operator, I would say such document would not be required if we had IPv6 terminals. But it is not the case and we need to get such reference even if it is not our only action to get such devices.
Actually, we do have IPv6 terminals. Verizon Wireless has shipped tens of millions of them.

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 20 Nov 2012 00:37:13 +1100

I made several comments on this document and are all included in Lorenzo's
comments below. Therefore I'm of the same opinion regarding WG adoption.

Hesham

-----Original Message-----
From: Lorenzo Colitti <[email-masked]>
Date: Monday, 19 November 2012 7:39 PM
To: <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

>also presents the problem that if the 3GPP standards are updated, the
>text becomes out of date.
>
>Third, IETF work is supposed to proceed in parallel with running code,
>not in the absence of running code. I very doubt there are two
>interoperable implementations that satisfy all these requirements
>(actually, I doubt that any real implementation satisfies even half of
>them). Attempting to specify these requirements will not change that.
>
>
>Moving on, at least these requirements are redundant and should be
>removed or replaced by a reference to the appropriate specs:
>
>
>provides DNS. Should the phone just information from one of them? Or
>should it list all of them in priority order?
>
>Internet-Draft 
><https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>
>directories: http://www.ietf.org/shadow.html

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 19 Nov 2012 06:30:45 -0800

Sent from ipv6-only Android
>>> [[david]] As an operator, I would say such document would not be
required if we had IPv6 terminals. But it is not the case and we need to
get such reference even if it is not our only action to get such devices.
millions of them.

Are those terminals capable of being used on any other network
effectively?  I believe the answer is no. Given vzw unique 3gpp and 3gpp2
network, their terminals are quite unique.

CB _______________________________________________

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 19 Nov 2012 06:36:46 -0800

>
> Because that draft properly updates RFC3316. This document does not
update RFC3316, it's something completely different.
> Does the IETF define an IPv4 profile? If not, why not?

Why no ipv4 profile?   Because ipv4 network behavior is emergent behavior
not an engineered behavior.

The definition of "working" on ipv4 is that it does not break something
that already works.... so working is defined by baggage. Given that the
only fully deployed ipv6 3gpp network is very unique and only one data
point,  it is not sufficient to create a repeatable model.

The goal of this doc, like 6204, is to do some more consensus based
engineering to better bootstrap our ipv6 deployments.

CB

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 19 Nov 2012 15:34:05 +0000

<bhs> Just to explain a bit of RFC 6204 history --  CableLabs and Broadband Forum had no difficulty (internal to their respective orgs) in defining requirements / device profiles for CE routers that are expected to attach to their respective access architectures. The reason these organizations came to IETF was so there could be requirements available for retail devices (that had no expectation of required compliance to any BBF or CableLabs spec) that wanted to understand what was needed to attach successfully to either access architecture. There are many additional requirements in the CableLabs eRouter specs and BBF TR-124i3 that describe requirements for CE routers that are intended only for those environments. Note that RFC 6204 (and 6204bis) do not reference any BBF or CableLabs spec. Rather, it is expected that those organization's specs will reference or be consistent with RFC 6204 (6204bis), and build upon that as the base for their architecture-specific requirements. In cases where BBF has total control over specifying an interface, BBF has been known to ask IETF for help with needed Layer 3 protocol definition and extensions and recommendations for appropriate requirements, but not for actual creation or publication of device or network element functional profiles or requirements.
Barbara

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 19 Nov 2012 22:51:08 +0100

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, November 19, 2012 11:40 AM
To: [email-masked]
Cc: IPv6 Ops WG
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

[ales] As an operator I *need* IPv6 profile document I can refer vendors to, you see other operators on the list requesting the same, so it is clearly an issue operators are trying
to address here. Honestly, I am still not getting what's wrong with this document intended to be a requirements list such as 6204(bis).

[ales] No, we don't and that's why we see the need to spend our efforts writing this requirements document. If we had them, we wouldn't be here.

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 19 Nov 2012 23:06:05 +0100

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, November 19, 2012 9:39 AM
To: [email-masked]
Cc: IPv6 Ops WG
Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-requirements-00.txt

Can we agree on that such a document is required?

[ales] I am expecting PD being supported in ~2 years timeframe, so it is definitely worth considering.