Subject: [v6ops] Charter clarification discussion

From: Fred Baker <[email-masked]>
Date: Thu, 16 Sep 2010 10:20:34 -0500

I'm looking at two charter issues that have been raised on the list recently, and hoping to clarify them in the charter. We haven't updated the charter in quite a while, so it may need updating. That said, some things that the charter was intended to say it doesn't appear to quite say, so it may be worth clarifying.

The two issues are: 
(1) Does v6ops discuss IPv4 issues in dual stack networks? My read of the second paragraph of the charter is that we look at operational issues that arise in dual stack networks, which would include IPv4 issues in such a network.
(2) Does v6ops look at coexistence issues and general operational issues, or only deployment issues?  My read of the second paragraph of the charter, again, is that we look at issues that arise in IPv6-only and dual stack networks, which would include operational and coexistence issues in such a network.

While I'm at it, I did some copy editing that should not change the meaning of the charter but might make it easier to read.

So here is my proposed update to the charter:

    ftp://ftpeng.cisco.com/fred/v6ops/v6ops-charter-diff.html
    ftp://ftpeng.cisco.com/fred/v6ops/v6ops-old-charter.txt
    ftp://ftpeng.cisco.com/fred/v6ops/v6ops-new-charter-00.txt

Comments?

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Sep 2010 18:40:44 +0200

Hi Fred,

>    ftp://ftpeng.cisco.com/fred/v6ops/v6ops-new-charter-00.txt

The meaning of "operational issues, including deployment and coexistence issues," isn't clear to me.
If it the same as "operational issues of the coexistence period, including those concerning deployments", maybe some wording similar to this might be easier to understand.

Note also a "Maintanence" typo in point 3

A separate mail will deal with a more general question.

Regards,
RD

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 21 Sep 2010 11:11:32 -0400

Fred,

I think the text changes help define the charter to better serve the
IPv4/IPv6 coexistence issues that will exist (so I agree with changes).

That said, in connection with our v4v6tran call last night (or this morning
depending on where people joined), we will need to solve the problem that
Can-Can raised with respect to issues related to the CGN issue (as it
relates to transition).

As I understand it, part of the whole IPv4/IPv6 transition issue is dealing
with IPv4 continuance while IPv6 is put in place.  Depending on the
transition scenario employed by a given operator, CGN/NAT444 may play a part
of the IPv4 continuance side (example, NAT444 used in a Dual-Stack Network).
By they way I am not arguing in favor of this versus other techs like
DS-Lite NAT64 etc - just presenting an example.

So the issue is raised, if a draft is up for discussion which deals with
this type of technology point (i.e. What addresses to use, how to use it, or
some other detail etc) will it be accepted for discussion?  As noted, in the
past, some members of the WG have been less then accepting of this type of
discussion (and I do understand their points), which is somewhat counter
productive if we are in fact trying to keep the IP services going while we
all exhaust the IPv4 pool and move to IPv6 while allowing consumers and
business to keep working unabated.

Additionally, there will be drafts presented which deal with sub-topics
around NAT444.  I know it was mentioned last night that other WGs can take
this on (say Behave or Ops area depending on topic), but one of the original
concerns back in July was that attempting to deal with various topics (which
all are connected in the big picture of continuance and transition) in
different WGs was that it may not spawn the right cohesiveness when dealing
with the separate but related topics.

Regards,

Victor K

On 16/09/10 11:20 AM, "Fred Baker" <[email-masked]> wrote:

> I'm looking at two charter issues that have been raised on the list recently,
> and hoping to clarify them in the charter. We haven't updated the charter in
> quite a while, so it may need updating. That said, some things that the
> charter was intended to say it doesn't appear to quite say, so it may be worth
> clarifying.
> 
> The two issues are:
> (1) Does v6ops discuss IPv4 issues in dual stack networks? My read of the
> second paragraph of the charter is that we look at operational issues that
> arise in dual stack networks, which would include IPv4 issues in such a
> network.
> (2) Does v6ops look at coexistence issues and general operational issues, or
> only deployment issues?  My read of the second paragraph of the charter,
> again, is that we look at issues that arise in IPv6-only and dual stack
> networks, which would include operational and coexistence issues in such a
> network.
> 
> While I'm at it, I did some copy editing that should not change the meaning of
> the charter but might make it easier to read.
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Sep 2010 11:20:26 -0400

> As I understand it, part of the whole IPv4/IPv6 transition issue is
> dealing with IPv4 continuance while IPv6 is put in place.

this is not clear, unless ipv6 is directly involved.

stretching, kludging, and natting ipv4 to make it last is orthoginal to
ipv6 deployment.  folk can and are using it and not deploying ipv6 at
all.

otoh, if you are also deploying ipv6, the ipv6 transport can be useful
in some of the tunneling schemes for the ipv4 kludges.  as can many
other tunnel transports.

randy

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Sep 2010 08:44:47 -0700

On Sep 21, 2010, at 8:11 AM, Victor Kuarsingh wrote:
> some other detail etc) will it be accepted for discussion? 

The working group adopted http://datatracker.ietf.org/doc/draft-ietf-v6ops-incremental-cgn, which is in the process of last call (with no comments since I opened the WGLC on 12 September). It is essentially what you just said. The primary purpose of the IPv6 working group is not the support of IPv4 networks, but as keeping IPv4 running for a while is necessary, yes the chairs will entertain such topics.

On the other hand, there are bits of this that properly belong in behave (as they relate to the topic of translation), softwire (as they relate to tunneling and encapsulation mechanisms), intarea, or opsarea. I'll encourage people to talk with the chairs of this and the other working groups to determine the best venue for their topic - not venue-shopping, but conversation. What would make it appropriate here is 
(1) it relates to a network in the coexistence phase (the network is bringing up IPv6 and has an IPv4 issue in the process) and 
(2) it is fundamentally of an operational nature.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 21 Sep 2010 10:20:51 -0700

> in some of the tunneling schemes for the ipv4 kludges.  as can many

+1

I thought Fred make this clear on the call last night v6ops will take
into consideration all architectures that involve IPv6, including the
IPv4 side of an IPv6 transition network (DS-lite, 6RD, DS+NAT44).  It
will not take into consideration IPv4-only network (NAT444 with no
IPv6).

Cameron

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Sep 2010 13:40:11 -0400

> I thought Fred make this clear on the call last night v6ops will ...

i was not aware of a v6ops call last night.  hmmmm.

randy

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Sep 2010 10:40:43 -0700

On Sep 21, 2010, at 10:20 AM, Cameron Byrne wrote:

> I thought Fred make this clear on the call last night v6ops will take into consideration all architectures that involve IPv6, including the IPv4 side of an IPv6 transition network (DS-lite, 6RD, DS+NAT44).  It will not take into consideration IPv4-only network (NAT444 with no IPv6).

That is literally what I said.

Randy, I'm kind of scratching my head here. If I read you correctly, you are of the opinion that only IPv6 issues need apply; IPv4 and IPv6 are literally ships in the night, numerous networks have a long history of running CGN (Verizon, at the Google conference a few weeks ago, said that they had 70 instances of 10.0.0.0/8 running in their network, and they are far from alone), and people with IPv4 operational problems need not apply. 

I agree that IPv4 operators are likely to have a pretty good handle on IPv4 issues. But I have trouble with the notion that IPv4 and IPv6 are ships in the night, especially if one is running in a tunneled/encapsulated architecture over the other or the two are running on the same hardware. It seems to me that a flaw in one has the distinct possibility of impacting the other.

If we agree that issues can arise on the IPv4 side that result from or are incidental to an IPv4+IPv6 network (including 6rd/4rd/ds-lite in the sense that both protocols are offered as services), I don't see how we can with a handwave exclude IPv4 issues from this working group. There is a judgement call that the working group will need to make in looking at issues of the form "does this in fact relate to it being IPv4+IPv6, or is it simply an IPv4 issue that should be taken to the *NOG/RIR in question?", but we already make those calls.

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Sep 2010 10:49:54 -0700

It was a v4tov6tran call. I invited v6ops folks to join if they were interested.

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 Sep 2010 13:54:26 -0400

> Randy, I'm kind of scratching my head here. If I read you correctly,
> you are of the opinion that only IPv6 issues need apply;

no.  that is not what i said.  i said ipv4-only issues need not apply,
e.g. nat4* when ipv6 is not used as an assist

as camron said, i suspect that we are in agreement.

randy

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Sep 2010 11:01:23 -0700

> as camron said, i suspect that we are in agreement.

ack

---

From: Tina TSOU <[email-masked]>
Date: Wed, 22 Sep 2010 13:55:14 +0800

Hi all,
In the end of the v4v6tran Webex meeting, we doubled checked with the  
v6ops chair and the AD, "if the network is not v6 only, not DS, it is  
the v4 network in the process transitioning to v6 (e.g. using  
NAT44(4), tunneling etc), is it in the (being updated) charter of  
v6ops?" The answer from the v6ops chair and the AD is yes. V4 network  
in the process transitioning to v6, DS, v6 only are in a package.
That means, the content of draft-yang-v4v6tran-ipv6-transition- 
guide-00 et al (the use cases, transition guide for cable, broadband,  
mobile for large scale operators) except the addressing scheme is in  
the (being updated) charter of v6ops.

B. R.
Tina
http://tinatsou.weebly.com

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Sep 2010 06:25:36 -0700

Fred and Randy,

There has been a great deal of marketing and bandwagon-jumping
wrt some of the transition technologies you are citeing here.
But, there needs to be an awareness of the Internet Routing
Overlay Network (IRON) which covers the needs of IPv6/IPv4
coexistence while providing stable Provider-Independent (PI)
addressing. IRON also provides a complete solution package
to many of the problems end user networks are facing, rather
than a one-dimensional short term band-aid. How can we bring
this into the discussion?

Thanks - Fred
[email-masked] 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fred Baker
> Sent: Tuesday, September 21, 2010 11:01 AM
> To: Randy Bush
> Cc: [email-masked]
> Subject: Re: [v6ops] Charter clarification discussion
> 
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Sep 2010 09:32:40 -0400

> this into the discussion?

the front door, like asking the appropriate wg to work on your draft?

we all have our axes to grind, don't we.  new edition of a+p coming
shortly.

randy

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Sep 2010 06:52:26 -0700

Hi Randy, 

> From: Randy Bush [mailto:[email-masked]] 
> Sent: Wednesday, September 22, 2010 6:33 AM
> To: Templin, Fred L
> Cc: Fred Baker; IPv6 Ops WG

IRON is already deep into the RFC publication process. It
will not need to go as a wg item, as it is an architecture
document that tells how the piece-parts fit together. The
piece-parts are VET and SEAL. First versions of these are
already published as RFCs (RFC5558; RFC5320) and stable
(bis) versions are ready for progression as RFCs. Should
I ask a wg to publish those?

> we all have our axes to grind, don't we.

Well, how do we sort this all out so that all options are
on the table? Sitting back and keeping quiet doesn't seem
to work very well.

Fred

> new edition of a+p coming shortly.
> 
> randy
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Sep 2010 07:27:46 -0700

On Sep 22, 2010, at 6:52 AM, Templin, Fred L wrote:

> IRON is already deep into the RFC publication process. It will not need to go as a wg item, as it is an architecture document that tells how the piece-parts fit together. The piece-parts are VET and SEAL. First versions of these are already published as RFCs (RFC5558; RFC5320) and stable (bis) versions are ready for progression as RFCs. Should I ask a wg to publish those?

As far as I know, this is an RRG project, one of many ways to redesign the Internet; RFC 5320 is "Experimental". You could move it from there to softwire, which deals with tunneling solutions, with the support of an operator that was deploying it.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Sep 2010 07:32:36 -0700

Hi Fred, 

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Wednesday, September 22, 2010 7:28 AM
> To: Templin, Fred L
> Cc: Randy Bush; IPv6 Ops WG
> already published as RFCs (RFC5558; RFC5320) and stable (bis) 
> versions are ready for progression as RFCs. Should I ask a wg 
> to publish those?
> 
> As far as I know, this is an RRG project, one of many ways to 
> redesign the Internet;

That's not quite correct. ILNP is about redesigning the
Internet; IRON is about working with the Internet we
already have.

Thanks - Fred

> RFC 5320 is "Experimental". You could 
> move it from there to softwire, which deals with tunneling 
> solutions, with the support of an operator that was deploying it.

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 22 Sep 2010 10:35:15 -0400

> Internet; IRON is about working with the Internet we

Can you put some explanation behind this statement?

                                  Ron

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Sep 2010 07:42:05 -0700

Hi Ron, 

> From: Ronald Bonica [mailto:[email-masked]] 
> Sent: Wednesday, September 22, 2010 7:35 AM
> To: Templin, Fred L; Fred Baker
> Cc: IPv6 Ops WG
> Subject: RE: [v6ops] Charter clarification discussion
> 
> > >

Sure. In the spirit of RFC 1955, IRON requires no changes
to hosts and no changes to most routers. Just like 6to4,
ISATAP, teredo and 6rd, IRON only requires that a few new
routers (or changes to a few existing routers) be deployed.

Thanks - Fred

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Sep 2010 08:00:30 -0700

> Can you put some explanation behind this statement?

I think I would phrase it a little differently.

ILNP is a derivative of GSE; in essence, it is a multihoming solution that treats the IPv6 prefix as a "locator" and the EID as its "identity". It has the effect of giving the edge network the appearance of PI addressing while in effect making the transit network only deal with PA prefixes. The big issue in GSE and its derivatives, besides the difference of opinion over the inclusion of the prefixes in the TCP/UDP checksum, is that the IPv6 EID is not guaranteed to be globally unique, only locally. Hence, there is a disambiguation facility in ILNP. It doesn't affect the ISP operational or business model apart from reducing their opex/capex related to the size of the route table, which I would argue is a huge win.

IRON is a derivative of ISATAP, and builds an overlay network that commoditizes the ISP networks using an encapsulation architecture similar to LISP's. It happens to be an IPv6 network; it could just as easily be XNS or anything else. I say that it commoditizes the ISP network because it uses the ISP simply for transport - the ISP has no control of the addressing used within the IRON overlay, and cannot without getting into the overlay network do any traffic engineering or much of anything else. To quote Fred on the phone the other night, one of its primary effects is to make the edge network independent of its ISP's addressing plan. One could make a similar statement about any tunnel/encapsulation scheme (of which we seem to have a new one on the table daily) that is not managed by the ISP itself.

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Sep 2010 11:13:28 -0400

> on the table? Sitting back and keeping quiet doesn't seem

i already make too much noise and spend too much time on this stuff when
real work (and this week, the beach) becons.

randy

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Sep 2010 08:54:22 -0700

Hi Fred,

Just a few clarifications on the IRON observations:

> IRON is a derivative of ISATAP, and builds an overlay network 
> that commoditizes the ISP networks using an encapsulation 
> architecture similar to LISP's.

LISP and IRON are quite different, however. LISP uses
a hard to manage global mapping system, whereas IRON
leverages the native Internet routing system. Mapping
system synchronization has always been recognized as
the achilles heel of map+encaps architectures; IRON's
solution is to not use a mapping system at all.

> It happens to be an IPv6 
> network; it could just as easily be XNS or anything else.

It may come as a shock to know that the civil aviation
industry is moving forward with plans to deploy an
OSI-based global aeronautical telecommuncations network
(yes - CLNP, NSAP, etc.)! IRON supports any-in-any
encapsulation, so CLNP-in-IP is one of the endless
array of combinations within scope. 

> I 
> say that it commoditizes the ISP network because it uses the 
> ISP simply for transport - the ISP has no control of the 
> addressing used within the IRON overlay, and cannot without 
> getting into the overlay network do any traffic engineering 
> or much of anything else.

To clarify just a bit, the edge network still uses the
ISP's addresing plan to configure its locators, so the
locators are provider-aggregated. Any kind of ISP traffic
engineering based on the locator addresses still applies
when IRON is used. Nested encapsulations (where the ISP
steers traffic through its own internal control points)
are also possible, and I assume are likely already widely
used today.

> To quote Fred on the phone the 
> other night, one of its primary effects is to make the edge 
> network independent of its ISP's addressing plan. One could 
> make a similar statement about any tunnel/encapsulation 
> scheme (of which we seem to have a new one on the table 
> daily) that is not managed by the ISP itself.

I'm not sure which other tunnel/encapsulation schemes you
are referring to. 6to4 and teredo are not managed by the ISP,
but they are not completely independent of the ISP's addressing
plan due to the embedded IPv4 addresses. ISATAP and 6rd are
dependent on the ISP's addressing plan, so I assume you are
not referring to those. Are there other systems I should
know about?

Thanks - Fred

> Sent: Wednesday, September 22, 2010 8:01 AM
> To: Ronald Bonica
> Cc: Templin, Fred L; IPv6 Ops WG
> ILNP is a derivative of GSE; in essence, it is a multihoming 
> solution that treats the IPv6 prefix as a "locator" and the 
> EID as its "identity". It has the effect of giving the edge 
> network the appearance of PI addressing while in effect 
> making the transit network only deal with PA prefixes. The 
> big issue in GSE and its derivatives, besides the difference 
> of opinion over the inclusion of the prefixes in the TCP/UDP 
> checksum, is that the IPv6 EID is not guaranteed to be 
> globally unique, only locally. Hence, there is a 
> disambiguation facility in ILNP. It doesn't affect the ISP 
> operational or business model apart from reducing their 
> opex/capex related to the size of the route table, which I 
> would argue is a huge win.
> 
> IRON is a derivative of ISATAP, and builds an overlay network 
> that commoditizes the ISP networks using an encapsulation 
> architecture similar to LISP's. It happens to be an IPv6 
> network; it could just as easily be XNS or anything else. I 
> say that it commoditizes the ISP network because it uses the 
> ISP simply for transport - the ISP has no control of the 
> addressing used within the IRON overlay, and cannot without 
> getting into the overlay network do any traffic engineering 
> or much of anything else. To quote Fred on the phone the 
> other night, one of its primary effects is to make the edge 
> network independent of its ISP's addressing plan. One could 
> make a similar statement about any tunnel/encapsulation 
> scheme (of which we seem to have a new one on the table 
> daily) that is not managed by the ISP itself.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Sep 2010 08:56:09 -0700

> Sent: Wednesday, September 22, 2010 8:13 AM
> To: Templin, Fred L

Have fun at the beach, Randy. I think it is almost exactly
8 years since you declared IPv6 operational and closed the
ngtrans working group:

http://www.atm.tut.fi/list-archive/ngtrans/msg01830.html
http://www.atm.tut.fi/list-archive/ngtrans/msg01617.html

Thanks - Fred

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Sep 2010 11:59:40 -0400

> 8 years since you declared IPv6 operational and closed the

well, we had been running it in production since the latter '90s

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 Sep 2010 12:03:50 -0400

> 8 years since you declared IPv6 operational and closed the

imiho, ngtrans produced a few useful things but was pretty much a flop.
it drowned in complexity and massive non-op clue.  i am amused to watch
a bunch of folk who did not live through ngtrans preparing to repeat the
lesson.

randy

---

From: "t.petch" <[email-masked]>
Date: Wed, 22 Sep 2010 18:54:08 +0200

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "Ronald Bonica" <[email-masked]>
Cc: "IPv6 Ops WG" <[email-masked]>
Sent: Wednesday, September 22, 2010 5:00 PM

> I think I would phrase it a little differently.

Another source of information is
draft-irtf-rrg-recommendation
which contains a summary, critique and rebuttal of these two proposals.

There are many other proposals there too, so don't get side-tracked:-)

Tom Petch
>
> ILNP is a derivative of GSE; in essence, it is a multihoming solution that
treats the IPv6 prefix as a "locator" and the EID as its "identity". It has the
effect of giving the edge network the appearance of PI addressing while in
effect making the transit network only deal with PA prefixes. The big issue in
GSE and its derivatives, besides the difference of opinion over the inclusion of
the prefixes in the TCP/UDP checksum, is that the IPv6 EID is not guaranteed to
be globally unique, only locally. Hence, there is a disambiguation facility in
ILNP. It doesn't affect the ISP operational or business model apart from
reducing their opex/capex related to the size of the route table, which I would
argue is a huge win.
>
> IRON is a derivative of ISATAP, and builds an overlay network that
commoditizes the ISP networks using an encapsulation architecture similar to
LISP's. It happens to be an IPv6 network; it could just as easily be XNS or
anything else. I say that it commoditizes the ISP network because it uses the
ISP simply for transport - the ISP has no control of the addressing used within
the IRON overlay, and cannot without getting into the overlay network do any
traffic engineering or much of anything else. To quote Fred on the phone the
other night, one of its primary effects is to make the edge network independent
of its ISP's addressing plan. One could make a similar statement about any
tunnel/encapsulation scheme (of which we seem to have a new one on the table
daily) that is not managed by the ISP itself.

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 22 Sep 2010 16:22:23 -0400

(props to Dr. Santayana)

As I always told my guitar students before I got fed up with working 
with children "Don't keep making the same mistakes!  There are plenty of 
new and more interesting mistakes you could be making!"

In the midst of compiling a survey or annotated bibliography of "the 
canon" of transition, coexistence and interoperability RFCs and drafts, 
I would agree that "drowning in complexity" is a sad but true metaphor. 
   I thought it would be helpful to organize, compare and contrast all 
the published approaches, but with so many alternatives that would be a 
tall order.

Maybe every new approach should be required to obsolete at least two 
previously published RFCs.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 22 Sep 2010 15:44:21 -0400

(props to Dr. Santayana)

In the midst of compiling a survey or annotated bibliography of "the 
canon" of transition, coexistence and interoperability RFCs and drafts, 
I would agree that "drowning in complexity" is a sad but true 
metaphor.   I thought it would be helpful to organize, compare and 
contrast all the published approaches, but with so many alternatives 
that would be a tall order.

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 22 Sep 2010 19:54:58 -0700

> the published approaches, but with so many alternatives that would be a

being comprehensive is not always a desirable feature.  There is in fact
a curatorial responsibility for sorting the wheat from the dross.