Fred Baker (fred | 22 Oct 02:09 2014
Picon

IETF 91 Preliminary Agenda

Lee and I have come up with a draft agenda. It has two documents on it that have not yet been updated; if they
aren’t updated by the filing deadline, we’ll be taking them off the agenda. If new drafts are filed by
the deadline and we see working group interest, we will adjust for that as well.

The filing deadline is 2014-10-27 (Monday) UTC 23:59.

http://www.ietf.org/proceedings/91/agenda/agenda-91-v6ops

Draft authors, we need to know whom to expect to be presenting, and we need whatever slides you expect to use.
We are planning about half an hour per draft, which we expect to be at least half discussion.
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tim Chown | 21 Oct 16:30 2014
Picon

Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt



Tim

On 21 Oct 2014, at 11:29, Gert Doering <gert-BgGAxIuQBdJeoWH0uzbU5w@public.gmane.org> wrote:

Hiya,

On Mon, Oct 20, 2014 at 11:38:29PM -0700, internet-drafts-EgrivxUAwEY@public.gmane.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

       Title           : Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
       Authors         : Ole Troan
                         Brian Carpenter
Filename        : draft-ietf-v6ops-6to4-to-historic-06.txt

Support.  Both for the cause as for the text as written.

It's good to see a respin of the draft, taking into account recent
developments in clients (HE) and networks (6rd) and making clear which
parts are problematic, and which "similar-looking" parts are not
(namely, 6rd, and non-relay-using 6to4 between two IPv4-only hosts)

Yes, very much so.

In the last bullet point of section 3, might add “, as is becoming increasingly common as ISPs who are unable to acquire additional globally unique IPv4 address space turn to CGN.” or words to that affect.

Anything to say about the use of the prefix in address selection policy tables (noting that 3ffe::/16 is still cited there)?

There’s a paragraph at the end that says:

  "Peer-to-peer usage of the 6to4 mechanism, not depending on the
anycast mechanism, might exist in the Internet, largely unknown to operators. This is harmless to third parties and the current document is not intended to prevent such traffic continuing."

which is a little at odds with the Historic status for 3056? If it’s made historic, and support removed, it would harm them…?

Tim
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Lorenzo Colitti | 21 Oct 13:42 2014
Picon

Re: draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

On Tue, Oct 21, 2014 at 3:12 AM, 神明達哉 <jinmei <at> wide.ad.jp> wrote:
I have a mixed feeling about the importance of the document.  I
personally don't think it worth publishing in its current form,
although I wouldn't be opposed to it if the wg thinks it's useful.

+1. The operational problems section boils down to one statement: "if you flash renumber, the results differ between operating systems" (i.e., section 3.2.2). That's a true statement, but pretty obvious from the preceding text.

The only other operational problems statement, in section 3.2.1, is not very useful: if you don't have addresses via DHCPv6 or SLAAC, then there's little point getting other information from DHCP. For this to work at all, IP addresses must be configured manually, and if you're using manual configuration, you might as well configure other information manually as well.

The rest of the draft before the appendix is a rehash of RFC 4862, which doesn't really add anything new.

On the other hand, the appendix, which documents the behaviour of various OSes under different conditions, is useful.

Given that, it would seem to make more sense for this document to focus only on the results of the investigation (i.e., only the appendix), and a concluding statement that notes that implementations differ in their behaviour, and that renumbering behaviour is substantially different.
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Liubing (Leo | 21 Oct 05:25 2014

Re: draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

Hi Jinmei,

Thanks for your comments. Please see replies inline.

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces <at> ietf.org] On Behalf Of 神明達哉
> Sent: Tuesday, October 21, 2014 2:13 AM
> To: Fred Baker (fred)
> Cc: v6ops <at> ietf.org
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> 
> At Sun, 19 Oct 2014 11:00:02 -0700,
> fred <at> cisco.com wrote:
> 
> > This is to initiate a two week working group last call of
> > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.

> > 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.
> 
> I have a mixed feeling about the importance of the document.  I personally
> don't think it worth publishing in its current form, although I wouldn't be
> opposed to it if the wg thinks it's useful.
> 
> Vagueness and ambiguity regarding M, O, and A flags (especially the first two)
> are well known, and it's not surprising that different implementations behave
> differently.  Since such a divergence can cause a critical operational issue, I
> see a value in documenting these.
[Bing] I believe it is well known among standard developers, participants and implementers who had paid
attention on it. However, since the ambiguity problem is not so explicit in current standard, the vast
administrators/operators out IETF might not quite familiar with it. I once talked with some operator
people, they were quite confused about the situation when they met the problem in their IPv6 testbed
networks. 
So, if there is an RFC explicitly stating the problems, I think it would be good for
administrators/operators to learn the fact before they actually deploying the networks. Also, the
document could be a formal reference for potential standard work in the future to clear the ambiguity in
current standards.

> On the other hand, the specific issues described in Section 3.2 don't seem to
> be very critical to me.
[Bing] I agree the issues might not be critical for some people. But maybe they are important concerns in
other situations. Considering we are just at the beginning stage of deploying IPv6, It might be hard for us
to judge the importance, but we could document the issues, at least it is not harmful. 

> In the case described in Section 3.2.1, the host would only have link-local
> addresses. 
[Bing] Or maybe self-generated ULAs. (But of course, it is not the point of this document.)

> Such a host wouldn't be able to do many useful things anyway
> (potentially, there may be some interesting scenarios for a completely
> isolated, single-link, autonomous network with only link-local addresses, but
> I suspect there are many other fundamental issues to solve for such
> environments before we even worry about the M/O/A flags).
[Bing] I agree there would be other fundamental issues, but the O flag behavior would also exist anyway.

> The issues described in Section 3.2 seem to be caused largely because they
> switch the address configuration mechanism (SLAAC to DHCPv6 or vice versa)
> in addition to renumbering.  While that could happen in theory, it seems to
> be a quite artificial discussion.
[Bing] The address configuration mechanism switching is a specific case of renumbering; another one is to
add a new address by DHCPv6 for the already SLAAC-configured hosts or vice versa. These use cases might
happen in enterprise networks when companies split, merge, grow, relocate, or reorganize. 

> Actually, I guess there should be more pragmatic examples of operational
> issues because of the described divergence and I wonder whether these
> minor cases are really the only things we can imagine (although I don't have
> a specific idea right now).  If these sections can be revised with more
> convincing examples, I would be more supportive about publishing it.
[Bing] Current draft only documents the operational issues caused by divergent behaviors identified in
the tests. In Appendix B, it documents a comprehensive analysis of the ambiguity. If we made a permutation
and combination of the divergence derived from the ambiguity analysis, there would be other divergence
that did not covered in our limited tests (focusing on current mainstream desktop/phone OSes). But since
it is only in theory, we just left it in the appendix as a hint to the administrators.

> Some specific comments (mostly editorial and nits) on the draft text:
> 
> - Section 1:
> 
>    The M, O and A
>    flags are advisory, not prescriptive.
> 
>   In my understanding, the A flag is quite prescriptive.  If a host
>   implementation doesn't perform SLAAC for a prefix information option
>   with A flag on, that implementation would be considered
>   non-compliant.  At the very least, the level of "advisory" vs
>   "prescriptive" is much different between M,O and A, so listing all
>   of them in this sentence seems to be misleading, if not simply
>   incorrect.
[Bing] A flag in definition is not prescriptive, RFC4862 only explicitly defined " If the Autonomous flag
is not set, silently ignore the Prefix Information option." 
However, A flag in implementations (as we tested) is prescriptive, and I also agree it should be. We might
need to be distinguish the description between the A/M/O flags.
Thanks for the good point.

> - Section 2.1: s/setting/settings/
> 
>    [...]  The following setting are all allowed:
> 
> - Section 2.2: s/setting/settings/
> 
>    [...]  The following setting are all
>    allowed:
[Bing] We'll revise accordingly. Thank you.

Best regards,
Bing

> --
> JINMEI, Tatuya
> 
> _______________________________________________
> v6ops mailing list
> v6ops <at> ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
fred | 19 Oct 20:00 2014
Picon

draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.  
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.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Robert Raszuk | 18 Oct 11:06 2014
Picon

Re: [GROW] Deaggregation data (was: Deaggregation by large organizations)

> IPv6 BPs could mandate best aggregates only.

You can't *mandate* anything in BGP until you have a way to
effectively enforce it regardless if this is v4 or v6 or v9.

It is not the problem of folks in shorts and sandals who type in BGP
policies, but as Randy said those in suits who care about their
respective businesses.

Today at most we can have Geoff very nicely illustrating the picture
at next RIPE or NANOG. But he does not have a way to issue fine
tickets to offenders :)

Best,
r.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Fernando Gont | 16 Oct 16:47 2014

Re: Preparing IETF 91 agenda

Hi, Fred,

We'd like to request a slot for discussing:

Filename: draft-gont-v6ops-ipv6-ehs-in-real-world.
Presenters: Jen Linkova & Fernando Gont

Thanks,
Fernando

On 10/06/2014 09:09 PM, Fred Baker (fred) wrote:
> As I mentioned last week, Lee and I are pulling together an agenda for IETF 91. The drop-dead date for new or
updated drafts is 27 October, and frankly it will work better if drafts arrive earlier - as we are looking
for working group commentary on them.
> 
> Current state of play:
> 
> IESG:
>     Jul 31  draft-ietf-v6ops-enterprise-incremental-ipv6
>     Sep  1  draft-ietf-v6ops-ipv6-roaming-analysis
> 
> IETF Last Call:
>     Sep 26  draft-ietf-v6ops-mobile-device-profile
> 
> Working Group Document updated since IETF:
>     Sep 18  draft-ietf-v6ops-design-choices
> 
> Individual Submission updated since IETF:
>     Aug 24  draft-v6ops-pmtud-ecmp-problem
>             On list, Ray Hunter suggests someone write "a draft summarizing the ICMP PTB problem"
>     Sep 10  draft-gont-v6ops-ipv6-ehs-in-real-world
>             There has been some discussion on-list. 
>     Sep 15  draft-anderson-v6ops-siit-dc-2xlat
>             No list commentary
>     Sep 18  draft-elkins-v6ops-multicast-virtual-nodes
>             Some commentary, not supportive
>     Sep 18  draft-wang-v6ops-xlat-prefix-discovery
>             A fair amount of discussion, mostly anti-NAT.
>     Sep 25  draft-ybai-v6ops-ipv6-for-openstack
>             no list commentary
>     Oct  5  draft-anderson-v6ops-siit-dc
>             Some list commentary
> 
> Working Group Document NOT updated since IETF:
>     Jun 18  draft-ietf-v6ops-dhcpv6-slaac-problem
>     Jul  4  draft-ietf-v6ops-ula-usage-recommendations
> 
> Individual Submission NOT updated since IETF:
>     Apr  7  draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
>     Jul  3  draft-liu-v6ops-running-multiple-prefixes
>     Jul  4  draft-sun-v6ops-xlat-multi
>     Jul  4  draft-yourtchenko-chown-rupik-v6ops-dad-3x
>     Jul 20  draft-wang-v6ops-flow-label-refelction
>     Jul 21  draft-liu-v6ops-dhcpv6-slaac-guidance
> 
> more data at http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@...
> https://www.ietf.org/mailman/listinfo/v6ops
> 

--

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@...
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Liubing (Leo | 11 Oct 12:04 2014

Multiple IPv6 Prefixes Operational Considerations-//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-02.txt

Hi, all

We've uploaded a new version of the draft.
As discussed in London, we modified it to a set of operational guidance instead of a set of problem statements.

Please have a review and comment whether you think it is a useful work in this working group.
Many thanks!

Best regards,
Bing

-----Original Message-----
From: internet-drafts@...
[mailto:internet-drafts@...] 
Sent: Saturday, October 11, 2014 6:01 PM
To: Boyang; Sheng Jiang; Liubing (Leo); Sheng Jiang; Boyang; Liubing (Leo)
Subject: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-02.txt

A new version of I-D, draft-liu-v6ops-running-multiple-prefixes-02.txt
has been successfully submitted by Bing Liu and posted to the IETF repository.

Name:		draft-liu-v6ops-running-multiple-prefixes
Revision:	02
Title:		Considerations for Running Multiple IPv6 Prefixes
Document date:	2014-10-11
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-liu-v6ops-running-multiple-prefixes-02.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-v6ops-running-multiple-prefixes/
Htmlized:       http://tools.ietf.org/html/draft-liu-v6ops-running-multiple-prefixes-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-running-multiple-prefixes-02

Abstract:
   This document describes several typical multiple prefixes use cases.
   Then analyzes potential operational issues and provides operational
   considerations of running multiple prefixes.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Ruri Hiromi | 9 Oct 10:04 2014

Re: Preparing IETF 91 agenda

Dear chairs,

Hi,
I submitted "draft-jpcert-ipv6vullnerability-check-00" today.
If v6ops gives a 3 to 5 minutes for me, I would like to talk about this.

http://datatracker.ietf.org/doc/draft-jpcert-ipv6vullnerability-check/

Regards,

P.S. I am still working on this.... until the deadline comes...

On 2014/10/07 9:09, Fred Baker (fred) wrote:
> As I mentioned last week, Lee and I are pulling together an agenda for IETF 91. The drop-dead date for new or
updated drafts is 27 October, and frankly it will work better if drafts arrive earlier - as we are looking
for working group commentary on them.
> 
> Current state of play:
> 
> IESG:
>     Jul 31  draft-ietf-v6ops-enterprise-incremental-ipv6
>     Sep  1  draft-ietf-v6ops-ipv6-roaming-analysis
> 
> IETF Last Call:
>     Sep 26  draft-ietf-v6ops-mobile-device-profile
> 
> Working Group Document updated since IETF:
>     Sep 18  draft-ietf-v6ops-design-choices
> 
> Individual Submission updated since IETF:
>     Aug 24  draft-v6ops-pmtud-ecmp-problem
>             On list, Ray Hunter suggests someone write "a draft summarizing the ICMP PTB problem"
>     Sep 10  draft-gont-v6ops-ipv6-ehs-in-real-world
>             There has been some discussion on-list. 
>     Sep 15  draft-anderson-v6ops-siit-dc-2xlat
>             No list commentary
>     Sep 18  draft-elkins-v6ops-multicast-virtual-nodes
>             Some commentary, not supportive
>     Sep 18  draft-wang-v6ops-xlat-prefix-discovery
>             A fair amount of discussion, mostly anti-NAT.
>     Sep 25  draft-ybai-v6ops-ipv6-for-openstack
>             no list commentary
>     Oct  5  draft-anderson-v6ops-siit-dc
>             Some list commentary
> 
> Working Group Document NOT updated since IETF:
>     Jun 18  draft-ietf-v6ops-dhcpv6-slaac-problem
>     Jul  4  draft-ietf-v6ops-ula-usage-recommendations
> 
> Individual Submission NOT updated since IETF:
>     Apr  7  draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
>     Jul  3  draft-liu-v6ops-running-multiple-prefixes
>     Jul  4  draft-sun-v6ops-xlat-multi
>     Jul  4  draft-yourtchenko-chown-rupik-v6ops-dad-3x
>     Jul 20  draft-wang-v6ops-flow-label-refelction
>     Jul 21  draft-liu-v6ops-dhcpv6-slaac-guidance
> 
> more data at http://datatracker.ietf.org/doc/search/?sort=status&activedrafts=on&name=v6ops
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@...
> https://www.ietf.org/mailman/listinfo/v6ops
> 

--

-- 
---------------
Ruri Hiromi
INTEC Inc.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Fernando Gont | 8 Oct 20:28 2014
Picon

Re: IPv6 Extension Headers in the Real World

On 10/06/2014 12:27 PM, Joe Touch wrote:
>
> Although I appreciate that everyone thinks that "this can be
> coordinated", we're seeing ample evidence to the contrary. It's useful
> to note here that NEITHER DOC REFERENCES THE OTHER, despite being
> written by the same author (which begs the question of "end run").

Joe, if you feel like making an ad-hominem accusation, at the very least
state what the basis of your accusations are. This is not the first time
you do it. Last recent one was based on seconding Fred Baker's claim
that I had requested adoption of this document to two set of wg chairs
-- which was simply *not true*. Making such assertions in public, based
on your own personal assumption's (or someone else's) (and without
apologizing in those cases where it is easy to prove that something
wasn't true), does not seem like a good way forward or even fair.

That said, there are different sets of authors in each doc that you
mentioned. I happen to be a co-author of all such documents. But I'm not
"the author". If you think that one document should reference another,
but did not, maybe it was just an error? Maybe when writing the I-D, the
other document had not yet been written? Maybe something else other than
a conspiracy theory?

If you infer some sort of Machiavellian plan regarding this document, I
just say "there isn't any". If you wonder, this is how each I-D was born:

the eh-filtering I-D is simply an IPv6 version of RFC7126. We got
RFC7126 done, and the IPv6 part was missing. That's how this I-D was born.

OTOH, draft-gont-v6ops-ipv6-ehs-in-real-world was born (later) when
trying to codify and summarize what we had been discussing at the IEPG
meetings (for more than a year now).

> If this is left to the WGs, then the WGs need to decide if they can
> manage each of these documents in the isolation the context that already
> has been allowed to exist and is already promoted by the author - or if
> that can *only* happen in a single doc.

As noted quite a few times, there have been many cases where there's has
been overlap among wg groups. For instance, anything that has to do with
ipv6 opsec can fit either v6ops or opsec. I personally don't see that as
a problem.

Thanks,
--

-- 
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Kossut Tomasz - Hurt | 8 Oct 15:52 2014

Re: Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

Hi,

Majority of modern smartphones from Sony, HTC, LG, Samsung, Nokia WP8.1 are compliant with CLAT+NAT64/DNS/DNS64

Together with Michał Czerwonka we created document with mandatory IPv6 requirements, close cooperation with vendors succeeded and we managed to launch first terminal (Xperia Z1) in September 2013, after 12 months we have 13% of IPv6 only mobile users in a network. If you are mobile operator and you thinking about IPv6 migration you won’t have any problems with Smartphones (except Iphones=NO CLAT support) the way is paved for you...

 

  1. Network Configuration (CLAT+NAT64+DNS)

Internet access is done by establishing one dedicated IPv6-only PDP/PDN context, network supports 464xlat architecture with DNS Dual-Stack (DNS64 feature is available only for domain “ipv4only.arpa”) - RFC 6877. CLAT implementation is mandatory for all devices

 

  1. UE, CPE vendor IPv6 mandatory requirements

2.1.Dynamic IPv6 Address Allocation + IID randomly generated (privacy address) +  UE shall use the IID given in PDP activation response message to configure its LLA (3GPP TS  23.060) http://www.3gpp.org/ftp/Specs/archive/23_series/23.060/.

2.2.Customer Side Translator function (CLAT) must be embedded (smartphone/tablet/router) as part of 464xlat architecture  RFC 6877. The CLAT must support ICMP, UDP, TCP, GRE and fragmented packet. clatd.conf  - may be generic where the domain for nat64 prefix discovery must be “ipv4only.arpa –  static configuration may be required.

https://android.googlesource.com/platform/external/android-clat/

2.3.MTU size & device interfaces - If the network send MTU size in RA message, then device must set it to the radio interface otherwise set the default value=1500B. The CLAT demon will calculate MTU size automatically for its interfaces (clat and clat4).

  1. IPv6 tethering - the CLAT helps Dual Stack tethering solution both USB/WIFI on the device , when APN is IPv6-only. The Global IPv6 and private IPv4 (clat) must be enabled on tethered LAN.

http://tools.ietf.org/html/rfc7278 (scenario 2)

3.1.RA – device sends RA message to tethered host with Ipv6 prefix information. Router lifetime set=9000 secs. Router sends periodically RA message – max. value 9000 secs.

3.2.DHCPv6 – device server relays PCO Ipv6 DNS'es addresses to tethered hosts.

3.3.DHCPv4 – device server relays  private IPv4 address and send DNS IPv4 (CLAT DNS-proxy)

3.4.Tethering & MTU size – device propagates MTU size 1500B to tethered clients interfaces ( Ipv4&Ipv6)

  1. IPv6 LTE UE  - the device must set EIT bit=1 in “Initial Attach” message.

Roaming - when APN with IPv6 protocol fails in roaming it must automatically revert back APN protocol to IPv4

 

One thing is still missing – different APN profiles(APN name+PDP type) for roaming –, there are two use cases:

Euinterent – (“EU Roaming Regulation III”) Internet APN available in UE countries (VPLMN subscriber is allowed to use VGGSN APN)

“Roaming Fallback to IPv4” creating separate roaming profile with APN name/PDP (now roaming fallback is based only on PDP type Android4.x/WP8.1)

 

Here are the benefits of extending APN profiles:

 

-       APN profiles and its “zones” HPLMN/VPLMN can separate IPv6 form IPv4

-       Separate APN for HPLMN (Ipv6 only APN for HPLMN)

-       Separate  APN for VPLMN roaming (fallback to IPv4 based on APN name)

-       Euinternet APN as secondary roaming profile for manual selection

 

Best Regards,

Tomasz Kossut

 

 

From: Heatley, Nick [mailto:nick.heatley <at> ee.co.uk]
Sent: Tuesday, October 07, 2014 11:31 AM
To: Lorenzo Colitti; IETF Discussion
Cc: v6ops <at> ietf.org WG; IETF-Announce
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

 

2. I stand by my earlier assessment that this document's requirements are over-broad, and in fact so broad as to harm adoption. There may well be operators or device implementers that seeing with such a high number of requirements may shy away in terror and think that deploying IPv6 in a mobile network is an impossibly high amount of work. That said, given that this document says clearly that it is not a standard, and that compliance is not required, the harm it does will be limited.

 

There may well be operators and device implementers that see the many individual “IPv6” RFCs and shy away. Transitioning technologies are still perceived as issues for the network.

If this cross-operator document states what is required on terminals to work in all major/predictable IPv6 scenarios, then it is giving such people a view of what a “healthy and robust” terminal implementation would consist of. If they are able to deliver on these requirements then they can supply a terminal ready for all business areas /all operator network scenarios.

(It certainly stops the feedback I’ve had from certain corners “that no other operators are asking for IPv6”, and “what you are asking for is a single operator roadmap which we won’t do”. That has been the reality here). So I don’t see how a consolidated demand-side view from operators who are really trying to introduce IPv6  in mobile can harm adoption in any way.

Regards,

Nick

 

 

From: v6ops [mailto:v6ops-bounces <at> ietf.org] On Behalf Of Lorenzo Colitti
Sent: 06 October 2014 08:30
To: IETF Discussion
Cc: v6ops <at> ietf.org WG; IETF-Announce
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-mobile-device-profile-13.txt> (An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC

 

 

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. 
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you.

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Gmane