Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt)

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Feb 2013 08:08:04 +0000

Joel, you're missing the point.

The draft has been finally approved by the IESG when some of us thought
it was on hold until somebody called consensus on the IPR question.

I'm not one for appeals but this is very close to an appealable move.

IMHO a WG Chair needs to make a formal call on the IPR question PDQ,
and if necessary, urgently request the IESG to rescind its approval.
I hope it isn't necessary, but it isn't my place to make the call.

Regards
   Brian Carpenter

On 01/02/2013 05:12, joel jaeggli wrote:
> On 1/31/13 5:47 PM, Ted Lemon wrote:
>> On Jan 31, 2013, at 6:26 PM, joel jaeggli <[email-masked]> wrote:
>>> Given an intended status of BCP, the next big step is IETF last call,
>>> which should not be construed as a reason to stop this discussion,
>>> quite the contrary.
>> Someone, I can't remember who (sorry!), pointed out that this
>> statement is true of Informational, but perhaps not of BCP.
> I think you mean vice-versa. if I'm wrong about it's current state then
> I missed something. version 9 and 8 still request the status of bcp as
> the wglc validated as well.
> 
>  we have hypothetically discussed whether the ipr is more palatable with
> an informational document.
>>    That is, if the document is merely intended to document the
>> existing practice that some vendor follows, that is a good thing which
>> we should publish; however, it shouldn't be a BCP if the IPR terms are
>> not found to be acceptable.
>>
>> I haven't looked at it in depth, but a brief skim of the updated IPR
>> report that went by yesterday looked like it was a bit outside of the
>> norm for IETF standards, since it mentions charging royalties.
> Definition  of what is RAND is somewhat fungible. It clearly is not in
> the style of non-assert clause which I would have no problems at all with.
>>
>>
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: SM <[email-masked]>
Date: Fri, 01 Feb 2013 07:51:24 -0800

Hi Brian,
>I'm not one for appeals but this is very close to an appealable move.

Yes.

Regards,
-sm

---

From: t.petch <[email-masked]>
Date: Fri, 1 Feb 2013 17:28:26 +0000

----- Original Message -----
From: "SM" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "IPv6 Operations" <[email-masked]>; <[email-masked]>
Sent: Friday, February 01, 2013 3:51 PM

> >I'm not one for appeals but this is very close to an appealable move.

Looking at the History on the tracker, on 30th January, Ron changed his
position from Discuss to Yes, and Approved Publication, so out it went.
Earlier on that day, China Mobile made a statement on IPR to which
Cameron responded with a query, seeking clarification.

I just observe.

Tom Petch

---

From: joel jaeggli <[email-masked]>
Date: Fri, 01 Feb 2013 10:25:24 -0800

> Joel, you're missing the point.
I'm also wrong. Since the IETF last call commenced on december 7th.
> it was on hold until somebody called consensus on the IPR question.

the dicussion point that kicked this off was.

	Folks,

	Draft-ietf-v6ops-464xlat is nearly ready for IESG approval.
	However, several IESG members, including me, are concerned that
	the WG has not yet considered the IPR declaration attached to this document.

	So, I will wait one more week before approving this document. If you are concerned
	about the IPR declaration, please post a message describing your concerns to the
	list. If no such concerns are posted, I will approve the draft on January 17.

The crucial point here is the working was aware at time of wglc of the IPR , there was however at the time, limited commentary on it (which is noted in the shepherds report). there was consensus to advance the document.

> I'm not one for appeals but this is very close to an appealable move.
It may well be.
> I hope it isn't necessary, but it isn't my place to make the call.
My solicitation of additional input did not yield additional insight, 
there are a limited number of people staking out positions, I'm not sure 
what to conclude from that. There are certainly some people that belive 
that documents ipr claims associated with them that carry these terms 
should not be published under any circumstances or least with serious 
reservations, I'm fine with that as a position but it doesn't square 
with the WGLC.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 01 Feb 2013 10:31:10 -0800

On 2/1/13 9:28 AM, t.petch wrote:
> Cameron responded with a query, seeking clarification. I just observe. 
> Tom Petch
It seems unlikely that a future response on their part will resolve the 
issue to the satisfaction of everyone.

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 1 Feb 2013 22:40:53 +0000

Folks,

It appears that we have a procedural problem. So, let's do the following:

- I ask the chairs to initiate a one week WG last call. The last call will be restricted to a discussion of whether this document should be published considering its IPR.
- If the WG concludes that the document should not be published, I will ask the IESG to rescind its approval of the draft
- If the draft reaches AUTH48 before the one week last call terminates, I will delay publication until the last call has yielded a formal conclusion

Now, for a little background regarding how we got to this point. As Joel points out, the IPR was disclosed well before the WG Last Call. It was also mentioned in the shepherd's write-up. When the document went to IESG review, the IESG questioned whether the WG had considered the IPR. So, I posted the message at http://www.ietf.org/mail-archive/web/v6ops/current/msg14886.html.

Discussion ensued, with some folks saying that the draft should be published and others saying that it should not. On Wednesday, I asked the chairs for a consensus call. Their sense of the mailing list was that there was consensus to publish. So, I cleared my DISCUSS and approved the document.

Looking back on the process, it may have been a bit too informal. There was never a formal last call, issued by the chairs. Nobody posted a message to the list declaring consensus, one way or another. So we will repeat the last call, this time a little more formally.

                                                         Ron

---

From: joel jaeggli <[email-masked]>
Date: Fri, 01 Feb 2013 14:55:44 -0800

> - I ask the chairs to initiate a one week WG last call. The last call will be restricted to a discussion of whether this document should be published considering its IPR.
Procedurally I am fine with requesting this. Given the desire  not have 
the announcement of it to fall over a weekend for many I would suggest 
that we run it from monday to monday rather than running today. that 
would also provide time for commentary on the proposal for an another LC.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 1 Feb 2013 23:00:10 +0000

> I hope it isn't necessary, but it isn't my place to make the call.

We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China Mobile on 464XLAT.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Feb 2013 23:15:41 +0000

> We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China…

The licensing declaration claims this option:

Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee.

This means that there is no guarantee that an open source implementation would not be subject to royalty, and no reason for commercial implementations to assume that the royalty will not be more than they can afford.   As I've mentioned in previous messages, I think that a BCP with such an IPR restriction is undesirable.

I currently oppose publishing the document as a BCP, but am willing to listen to arguments to the contrary.   I would support publishing the document as informational.

---

From: james woodyatt <[email-masked]>
Date: Fri, 01 Feb 2013 15:27:18 -0800

> I currently oppose publishing the document as a BCP, but am willing to listen to arguments to the contrary.   I would support publishing the document as informational.

My position is the same as what Mr. Lemon declared above.

--
james woodyatt <[email-masked]>
core os networking

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 1 Feb 2013 15:27:56 -0800

Sent from ipv6-only Android
On Feb 1, 2013 3:00 PM, "Fred Baker (fred)" <[email-masked]> wrote:
> We actually thought we had asked on two occasions and not gotten much of
a response. However, consider this that request. We are interested in the
working group's opinion on the IPR claims by China Mobile on 464XLAT.

Since you ask about the claim, I appeal to the group's common sense. The
draft plainly states this is just putting rfc 6145 and 6146 in series.
Both of those rfcs have roots in work from nat-pt in 2000.

It would be very unfortunate if we have to cower at an ipr claim that
asserts our own standards against us (the ietf)

CB

Ps. I am not a lawyer. And, you alread told me the ietf is not a
court...thx! _______________________________________________

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 2 Feb 2013 00:48:02 +0000

On Feb 1, 2013, at 3:27 PM, Cameron Byrne <[email-masked]<mailto:[email-masked]>> wrote:

Since you ask about the claim, I appeal to the group's common sense. The draft plainly states this is just putting rfc 6145 and 6146 in series.  Both of those rfcs have roots in work from nat-pt in 2000.

It would be very unfortunate if we have to cower at an ipr claim that asserts our own standards against us (the ietf)

This is of course why we have asked China Mobile for the substance of the claim. If that is literally their claim, I wish them luck when it comes to enforcing it. But *that* question is not ours. The question for us is whether, in the presence of the claim of IPR, we want to publish the draft at all, and if so, with what status.

There is a part of me that would be very happy for the working group to decide it didn't want to publish the draft at all, and to state that the reason is an IPR declaration that looks essentially vacuous and has been neither explained nor substantiated by China Mobile. But that's just me.

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Feb 2013 12:40:29 +0900

> This means that there is no guarantee that an open source
> implementation would not be subject to royalty, and no reason for
> commercial implementations to assume that the royalty will not be more
> than they can afford.  As I've mentioned in previous messages, I think
> that a BCP with such an IPR restriction is undesirable.

<aol>

> I currently oppose publishing the document as a BCP, but am willing to
> listen to arguments to the contrary.  I would support publishing the
> document as informational.

with a change to "china mobile's blah blah"

randy

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Feb 2013 20:07:57 -0800

> I currently oppose publishing the document as a BCP, but am willing to listen to arguments to the contrary.   I would support publishing the document as informational.

I support this position as well.

If it is to become BCP, it should be available to open source without royalty.

Owen

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 1 Feb 2013 20:13:01 -0800

Sent from ipv6-only Android
On Feb 1, 2013 8:09 PM, "Owen DeLong" <[email-masked]> wrote:
> >> We actually thought we had asked on two occasions and not gotten much
of a response. However, consider this that request. We are interested in
the working group's opinion on the IPR claims by China Mobile on 464XLAT.
implementation would not be subject to royalty, and no reason for
commercial implementations to assume that the royalty will not be more than
they can afford.   As I've mentioned in previous messages, I think that a
BCP with such an IPR restriction is undesirable.
> If it is to become BCP, it should be available to open source without
royalty.

Once again,  I am not a lawyer. But it is open source and royalty free
everywhere except China where the patent was issued.

CB

---

From: Ray Hunter <[email-masked]>
Date: Sat, 02 Feb 2013 05:41:50 +0100

> We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China…
Speaking as an individual, and as someone whose name appears in the
"with thanks" section of this document, I'm uncomfortable with the
thought that anyone would be swayed or otherwise persuaded to pay an as
yet to be defined commercial licence fee for this technology, due to an
IETF document that I've contributed to pro bono. I'm therefore not
comfortable with the intended BCP status combined with the current IPR
statement. Little guys can't afford IPR lawyers. No matter how much
merit the IPR claim has (or not).

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Feb 2013 08:11:57 +0000

> Discussion ensued, with some folks saying that the draft should be published and others saying that it should not. On Wednesday, I asked the chairs for a consensus call. Their sense of the mailing…

afaik that consensus call was not copied to the list. That was perhaps unfortunate.

> We actually thought we had asked on two occasions and not gotten much of a response. However, consider this that request. We are interested in the working group's opinion on the IPR claims by China…

My opinion is that the IPR claim is no more worrisome than many others the IETF
has chosen to live with, so the document should proceed as a BCP. The claim
is on record for any implementor to consider, regardless of the status of
the document.

     Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Feb 2013 13:11:26 +0000

> with a change to "china mobile's blah blah"

Good point.

---

From: joel jaeggli <[email-masked]>
Date: Sat, 02 Feb 2013 23:33:11 -0800

> afaik that consensus call was not copied to the list. That was perhaps unfortunate.
It was literally a call, as in voice.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 3 Feb 2013 15:07:15 +0000

> It was literally a call, as in voice.

Aren't consensus calls in meetings supposed to be repeated on the mailing list?

---

From: Erik Kline <[email-masked]>
Date: Mon, 4 Feb 2013 15:20:20 +0900

> There is a part of me that would be very happy for the working group to
> decide it didn't want to publish the draft at all, and to state that the
> reason is an IPR declaration that looks essentially vacuous and has been
> neither explained nor substantiated by China Mobile. But that's just me.

I could definitely agree with this.

At the very least I would not be in favor of any standards-level
status above {experimental,informational}.

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Feb 2013 10:04:35 +0000

> status above {experimental,informational}.

This.

Tim

---

From: Warren Kumari <[email-masked]>
Date: Mon, 4 Feb 2013 10:20:20 -0500

>> neither explained nor substantiated by China Mobile. But that's just me.

I have not (and will not) read the claims in the IPR, and so I cannot form my own opinion of the IPR….

> status above {experimental,informational}.

I would prefer that this just goes away. If that doesn't happen, I can live with experimental or informational.
I really don't see how this can be a BCP if it is unclear if folk can implement…

W

--
The plural of anecdote is not evidence.
        -- Bill Lockyer, California Attorney General

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 4 Feb 2013 09:34:23 -0800

> I have not (and will not) read the claims in the IPR, and so I cannot form my own opinion of the IPR….

If you cannot form an opinion, then do not form an opinion... yet you
sent this mail and gave your opinion.  So, i am lost.  You are not the
only person on the list to make this statement and lose me in the
process, so i assume i am somehow missing something.  But, let's
explore a little.

I do encourage you to form an opinion.  I am sure the IETF's own
website is not too encumbering to you, so allow me to link you to the
relevant parts.

China Mobile filed an IPR disclosure to the IETF about a Chinese
patent they own https://datatracker.ietf.org/ipr/1730/

The relevant part is the date of the application / grant June 26,
2009.  We don't know the details of that patent, but I have  the
feeling we do not need those details.

Now, if you may review
http://www.ietf.org/mail-archive/web/v6ops/current/msg00917.html

You will see discussion on the v6ops list where this is said:  "I
wrote about the v4-v6-v4 case where IPv4 clients sit behind a CPE or
layer in the stack that translates their IPv4 packets into IPv6
packets using SIIT (= stateless) and then the resulting IPv6 packets
flow through the same NAT64 translators that IPv6 hosts that want to
talk to the IPv4 world also use." by one  Iljitsch van Beijnum.  This
is almost exactly the abstract of 464XLAT.

This nearly perfect summary of 464XLAT has a time stamp of 25 May
2008, over  a year before the IPR was granted.

I am not asking anyone to change an opinion, i am not a lawyer, i am
just providing some open data points.

CB

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Feb 2013 17:54:03 +0000

On Feb 4, 2013, at 12:34 PM, Cameron Byrne <[email-masked]> wrote:
> If you cannot form an opinion, then do not form an opinion...

There is actually no benefit to any of us to try to form an opinion about the validity of any IPR claim.   It is not we who would actually be responsible for deciding whether the IPR claim has been infringed if a claim of infringement were made.  Indeed, in making such a determination we might expose ourselves to liability, should the court rule differently.

So whether or not the working group decides to publish this as a BCP, the working group absolutely should not take a position on the validity of the IPR, as you have proposed it do.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 04 Feb 2013 17:58:34 +0000

> process, so i assume i am somehow missing something.  But, let's

You possibly are.  If Warren reads a USPTO patent and then his employer
violates it either by accident or design, and then gets sued for patent
violation, then they could end up in 3x damages territory for wilful
infringement if the law suit is successful.  Because of this, people in
large companies tend to have very clear rules about certain types of people
not reading patents.  As this is a chinese patent, it's less clear what the
rules might be, but it's entirely possible that Warren's employer might
have put a blanket ban in place on reading patents in general.

> patent they own https://datatracker.ietf.org/ipr/1730/

This isn't very useful either: the patent is in chinese.  I don't read
chinese, so have no idea what it's saying, and am not prepared to use
google translate to try to work it out.  I support Fred's formal request to
CM to clarify their position on the patent and its application to this ID.

Nick

---

From: Warren Kumari <[email-masked]>
Date: Mon, 4 Feb 2013 14:20:42 -0500

On Feb 4, 2013, at 12:34 PM, Cameron Byrne <[email-masked]> wrote:

> sent this mail and gave your opinion.  

I cannot form an opinion on the validity / claims in the IPR -- Nick and Ted saved me the trouble of explaining why… Even if I could read the application / patent I, not being a lawyer (and not wanting to play one on TV), I probably wouldn't be able to figure out what exactly was being claimed...

Luckily, the validity, color, flavor, etc isn't important -- what is important is if folk (like small players, the open source community) can implement this without royalty and without fear of being the one fighting the claims…

> So, i am lost.  You are not the

So, as I said, I'm not a lawyer, nor do I want to be one, but what I *think* you are saying is that this is prior art, and so the claims are not valid? 

If this is what you are saying, it seems (to me at least) to make this all the more worrying.
If Joe Schmo implements this, based on the assumption the claims are not valid, doesn't he end up potentially being the one stuck in lawsuits over this? And if he assumes it is valid (which is safer), he possibly has to pay some (unstated) royalty...

If that is not what you were saying, please ignore the above...

> just providing some open data points.

Neither (obviously) am I -- which is why unclear legal stuff scares me, and I default to the "Arrrgh, run away" stance…

W

--
Hope is not a strategy.
      --  Ben Treynor, Google

---

From: joel jaeggli <[email-masked]>
Date: Mon, 04 Feb 2013 16:20:12 -0800

> So whether or not the working group decides to publish this as a BCP, the working group absolutely should not take a position on the validity of the IPR, as you have proposed it do.
The IETF does not take a position on the validity of an ipr disclosure 
on a published or unpublished document.

you as an individual may take any position you like.

The question is, given the disclosure as it exits  are we comfortable 
with the wglc/ietf lc decision to publish, do we not want it to be a 
bcp, or should it not be published?

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Feb 2013 14:41:33 +0100

I'm fine with publishing this considering the IPR.

I would much have preferred this to be an informational document though.
as it can hardly be said to be best current practice for how to deliver IPv4 service.
- native IPv4 is.
- even in an IPv6 only access network, there are better solutions; e.g. MAP-E, DS-lite...

464xlat is what's left when the operator (or your host implementation) doesn't support anything else.
the smallest common denominator isn't best current practice.

cheers,
Ole

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 6 Feb 2013 16:26:23 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole
> Troan
> Sent: Wednesday, February 06, 2013 2:42 PM
> To: joel jaeggli
> Cc: IPv6 Operations; [email-masked]
> Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of Stateful andStateless
> Translation' to Best CurrentPractice (draft-ietf-v6ops-464xlat-09.txt)
> 

There are better solutions, there is no doubt about it, but there are also scenarios where
the encapsulation may be seen as too much of an overhead (e.g. mobile, where there
is enough encapsulation/tunnelling overhead already), so translation can be a better
fit.

> the smallest common denominator isn't best current practice.

I don't think I can agree to it. 464xlat extends NAT64 with the 4-to-6 function on the host,
so it can carry IPv4 traffic over NAT64. Again referring to mobile where tunnelling would
work, but translation less of an overhead from transport point of view..

> Ole

Cheers,
Ales

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 6 Feb 2013 15:48:09 +0000

I agree with Ales to translation being better in mobile environment.

Overall, I do think that if 464XLAT were to be "informational", then we
would be better off.

Also, let's not forget that there is MAP-T as well - all about
translation. :-) The challenge in all of this is that the UE needs to be
mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE
dependency. 

Cheers,
Rajiv

-----Original Message-----
From: Vízdal Aleš <[email-masked]>
Date: Wednesday, February 6, 2013 10:26 AM
To: Ole Troan <[email-masked]>, Joel jaeggli <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [v6ops] Protocol Action: '464XLAT:
Combination	of	Stateful	andStateless Translation'
to	Best	CurrentPractice	(draft-ietf-v6ops-464xlat-09.txt)

>> - even in an IPv6 only access network, there are better solutions; e.g.
>>MAP-E, DS-
>> lite...
>
>> 464xlat is what's left when the operator (or your host implementation)
>>doesn't support
>> anything else.

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 6 Feb 2013 22:54:09 +0100

Rajiv, Guys,

<my_mobile_hat="on">

> From: Rajiv Asati (rajiva) [mailto:[email-masked]]
> Sent: Wednesday, February 06, 2013 4:48 PM
> To: Vízdal Aleš; Ole Troan; joel jaeggli

Thanks, the industry needs a shipping solution soon as dual-stack is not solving
the ipv4 exhaustion problem (that's why I believe it's taking so much time to introduce
it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze ipv6 introduction.

> Overall, I do think that if 464XLAT were to be "informational", then we

BCP will give the industry the signal what to support ... this is not clear to them yet.	

> mucked up (whether 464XLAT or MAP-T or MAP-E..) and that's a HUGE

btw. According to https://datatracker.ietf.org/ipr/1731/ MAP-T is IPR'd by 
ChinaMobile as well claiming the same patent as for 464xlat. Given that
MAP-E does not fit (due to encapsulation overhead), MAP-T and 464xlat 
are equal from this point of view, but 464xlat is more advanced as there 
is a running code available (at lest for android) and this is something that 
should really matter to the IETF.

> Rajiv

PS. To my experience the business is not taking the best / nicest solution
available, but the one that fits the business the best.

Cheers,
Ales

</>

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Feb 2013 18:17:30 -0800

> - even in an IPv6 only access network, there are better solutions;

ds-lite is soooo wonderful.  it has all the advantages of nat in the
core and having to replace all the cpe.

map-e, aka stateless a+p, is about as clean a solution as you're gonna
get in this space.

and, as you point out, 464xlat is not a really good practice let alone
best.  and it is encumbered.

randy

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Feb 2013 18:49:56 -0800

> map-e, aka stateless a+p, is about as clean a solution as you're gonna

Send code

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Feb 2013 18:59:28 -0800

>> map-e, aka stateless a+p, is about as clean a solution as you're gonna

running at janog

https://www.seil.jp/community/node/71

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Feb 2013 19:02:20 -0800

> https://www.seil.jp/community/node/71

sorry, wrong url

https://www.seil.jp/community/node/97

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 6 Feb 2013 19:06:32 -0800

> https://www.seil.jp/community/node/97

On a 3gpp mobile network?

Thought so.

CB

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Feb 2013 19:07:04 -0800

> https://www.seil.jp/community/node/97

oops.  confession.  siel is the cpe which iij ($dayjob) produces.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Feb 2013 19:17:27 -0800

>>> send code

next you're gonna say you don't want it in magenta comic sans :).  gimme
a break.

randy

---

From: MAWATARI Masataka <[email-masked]>
Date: Thu, 07 Feb 2013 12:21:14 +0900

Hi,

Thank you all for your comments.

* On Wed, 6 Feb 2013 22:54:09 +0100
* Vizdal Ales<[email-masked]> wrote:

> > To: Vizdal Ales; Ole Troan; joel jaeggli

Excuse me.
Today's discussion is not whether a solution is better or not depending
on using encap/decap or translation.  I believe that it depends on
operators and their operating networks, and it is not time to do
competition.
We are essentially discussing which document category should we adopt
for the draft with IPR.  (Validity of the IPR is another story)

Yes.

> should really matter to the IETF.

I am aware that MAP-T also is IPR'd.  Sad.

> available, but the one that fits the business the best.

Kind Regards,
Masataka MAWATARI

---

From: Xing Li <[email-masked]>
Date: Thu, 07 Feb 2013 11:54:30 +0800

Hi, Vízdal and All,

> should really matter to the IETF.
FYI: The stateless double translation (one of the origins of MAP-T) is 
introduced in Section 5.2 "Double IVI" of 
http://tools.ietf.org/id/draft-xli-behave-ivi-02.txt , which is 
published on June 13, 2009, earlier than June 26，2009.

Regards,

xing

---

From: Owen DeLong <[email-masked]>
Date: Wed, 6 Feb 2013 20:07:43 -0800

> it in mobile), but ipv4-over-ipv6 does, so will hopefully catalyze ipv6 introduction.

How does IPv4-over-IPv6 do anything that dual-stack doesn't accomplish?

Neither one addresses IPv4 exhaustion except to the extent that IPv6 implementation
reduces dependence on IPv4.

Owen

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Feb 2013 20:27:51 -0800

> How does IPv4-over-IPv6 do anything that dual-stack doesn't accomplish?

v4 over v6 is looking forward to the day when IPv6-only networks are the 
rule rather than the exception, but there is still a need to reach 
v4-only resources outside the network. The problem is that for this 
purpose it's worse in many ways than the current solution for end-user 
networks, NAT on the inside network (i.e, dual stack).

Doug

---

From: Shishio Tsuchiya <[email-masked]>
Date: Thu, 07 Feb 2013 13:48:04 +0900

(2013/02/07 12:06), Cameron Byrne wrote:
> On Feb 6, 2013 7:02 PM, "Randy Bush" <[email-masked] <mailto:[email-masked]>> wrote:
>  >

MAP-E implementation report is here.
http://tools.ietf.org/html/draft-janog-softwire-report-01

There are 7 vendors and 9 implementations,include 2 Open sources(OpenWRT and ASAMAP) and Linux/BSD Kernel(by IPI).

Regards,
-Shishio

---

From: MAWATARI Masataka <[email-masked]>
Date: Thu, 07 Feb 2013 16:34:41 +0900

Hi,

* On Thu, 07 Feb 2013 11:54:30 +0800
* Xing Li <[email-masked]> wrote:

> Hi, Vizdal and All,

It's a really mystery-shrouded claim.

Thank you for your information.

Kind Regards,
Masataka MAWATARI

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 7 Feb 2013 18:05:21 +0100

> How does IPv4-over-IPv6 do anything that dual-stack doesn't accomplish?

It's the other way around as dual-stack does not accomplish what ipv4-over-ipv6
in some cases can. Dual-Stack still requires an IPv4 address to be assigned to an end 
host and consumes an IPv4 address & IPv6 prefix per subscriber. I am looking for 
an IPv6 only solution that does not require an IPv4 address to be assigned to an end 
host by the Operator.
 
> reduces dependence on IPv4.

464xlat does as Operator does not need to assign an IPv4 address to an end host.

Ales

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Feb 2013 11:35:35 -0800

> an IPv6 only solution that does not require an IPv4 address to be assigned to an end 

464xlat requires an IPv4 address on the end host as well. I don't see any difference
between 464xlat vs. CGN other than having an IPv6 tunnel carrying the middle
traffic instead of an IPv4 intermediary address range. It's still IPv4 through two
layers of NAT. Who cares whether the middle layer is IPv6 or IPv4? I don't see
a meaningful difference.

> 464xlat does as Operator does not need to assign an IPv4 address to an end host.

The network operator doesn't assign an IPv4 address to the end host today. What you
really mean is that the operator doesn't have to assign a globally unique address to
the subscriber gateway WAN port, but that's equally addressed in dual-stack with
the use of 100.0.0.0/10 space and CGN.

6 of one, half-dozen of the other.

Owen

---

From: Philipp Kern <[email-masked]>
Date: Thu, 7 Feb 2013 22:08:05 +0100

Owen,

> layers of NAT. Who cares whether the middle layer is IPv6 or IPv4? I don't see

you need to maintain and distribute that further intermediary address
range. To be honest I'd like to have 4to6 translation on the end hosts
by provisioning them with the NAT64 prefix. This would allow me to only
hand out IPv6 instead of having to maintain two routing planes, which is
at least one cost, as this might involve two separate routing protocols
for IPv4 and IPv6.

Clients that don't care about IPv4 anymore (because they don't use
legacy software employing IPv4 literals, for instance) can then simply
deactivate it and there's less IPv4. Yay.

So I care about the middle layer, even though it might not matter
much for the regular end-user of a mobile hotspot.

Kind regards
Philipp Kern

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 7 Feb 2013 23:38:26 +0200

> the use of 100.0.0.0/10 space and CGN.

Ales speaks here about 3GPP networks and there the operator assigns every
end device (UE) with a private or global IPv4 address if a dual-stack capable
bearer is used (I'll leave now the deferred address allocation away for a
reason). 464XLAT really does help here in that sense.. in 3GPP networks.

- Jouni

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 7 Feb 2013 21:46:53 +0000

Hi Ales, 

> BCP will give the industry the signal what to support ... this is not
>clear 
> to them yet.	

Does it really matter, given that the 60-80% of mobile UE industry means
iOS and Android? Would Google/Android and Apple/iOS get swayed by BCP vs.
Informational status?

I do support 464XLAT becoming an RFC sooner than later, because it could
take 2-5yrs to be widely available/used on various Android UEs.

	After all, the users can't be forced to upgrade the
	software on their mobile UEs to get IPv6, let alone
	464XLAT or MAP. Heck, my tablet running Android OS
	doesn't support IPv6 (and can't be upgraded).

With informational status, 464XLAT could bypass the IPR entanglement to
become an RFC, IMO.

Cheers,

Rajiv

-----Original Message-----
From: Vízdal Aleš <[email-masked]>
Date: Wednesday, February 6, 2013 4:54 PM
To: Rajiv Asati <[email-masked]>, Ole Troan <[email-masked]>, Joel
jaeggli <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: RE: [v6ops] Protocol Action: '464XLAT: Combination of Stateful
andStateless Translation' to Best CurrentPractice
(draft-ietf-v6ops-464xlat-09.txt)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Feb 2013 09:00:48 +1100

In message <[email-masked]>, Jouni Korhonen wri
> reason). 464XLAT really does help here in that sense.. in 3GPP networks.

And host based DS-lite also works.  Both at designed to work with IPv6 only
uplinks.  With DS-lite you don't have to nat in the handset when tethering
as the operator does the natting for you.  There is a 20 byte penalty for
DS-lite compared to 464XLAT.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 7 Feb 2013 22:06:23 +0000

Actually, 464XLAT could help to simplify the network design involving NAT
in a large scale 3GPP deployment.

If dual-stack were to be used on 3GPP interface, then using 100.64.0.0/12
would mean using virtualized routing (e.g. L3VPNs) between one or more
PGWs and NAT device, since each PGW can easily exhaust 100.64/12 block.

Of course, this is not an issue if NAT is done on the PGW (unless PGW
supports 1M+ subscribers with 4+ PDNs each, and in that case, we would be
back to needing virtualized NAT).

Cheers,
Rajiv

-----Original Message-----
From: Jouni Korhonen <[email-masked]>
Date: Thursday, February 7, 2013 4:38 PM
To: Owen DeLong <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of
Stateful	andStateless Translation' to Best
CurrentPractice	(draft-ietf-v6ops-464xlat-09.txt)

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 7 Feb 2013 22:08:46 +0000

Mark,

Yes, theoretically speaking. However, video optimizers, DPI, transparent
caching, URL filtering etc. all of that would break, if they were
subjected to tunneled traffic.

Cheers,
Rajiv

-----Original Message-----
From: Mark Andrews <[email-masked]>
Date: Thursday, February 7, 2013 5:00 PM
To: Jouni Korhonen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] Protocol Action: '464XLAT: Combination of

>> >>> Neither one addresses IPv4 exhaustion except to the extent that
>>IPv6 impl
>> ementation
>> >> 464xlat does as Operator does not need to assign an IPv4 address to
>>an end
>>  host.
>> > 
>> > The network operator doesn't assign an IPv4 address to the end host
>>today. 
>> What you
>> > really mean is that the operator doesn't have to assign a globally
>>unique a
>> ddress to
>> > the subscriber gateway WAN port, but that's equally addressed in
>>dual-stack
>>  with

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Feb 2013 14:04:48 -0800

> reason). 464XLAT really does help here in that sense.. in 3GPP networks.

I suppose that's one way to think of it. Personally, I think of every mobile device
as a portable router (since mobile hotspot has become such a common
technology) and therefore don't really see it as different from the home gateway
in the residential or SMB scenario.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Feb 2013 14:12:12 -0800

It's a /10, not a /12, but point taken, you can trade some issues for other issues
by using v6 as the middle-ground addressing instead of v4.

Interestingly, I believe your math below (1M+ subscribers @ 4+PDNs) is
correct for the /10, but that it would be 1/4 that for a /12.

Owen

On Feb 7, 2013, at 14:06 , "Rajiv Asati (rajiva)" <[email-masked]> wrote:

>>> today. What you
>>> unique address to
>>> dual-stack with

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 8 Feb 2013 00:32:15 +0200

> in the residential or SMB scenario.

Just to point out that 3GPP operators here have no choice. The IPv4 address
assignment stuff is bolted in the system & link model. 

- Jouni

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Feb 2013 09:34:34 +1100

In message <[email-masked]>, "R
> subjected to tunneled traffic.

464XLAT is tunneled as well as far as the IPv4 content is concerned.
You save 20 bytes of tunnel overhead, you do *not* remove it.  You still
have to deal with PMTU issues.

DS-lite does not preclude DPI, transparent caching, URL filtering.
If you current DPI should be able to handle IP in IP already as it
is used for vpns.

If you don't have per customer configuration you can even do this.

Internet - transparent cache/url filter - AFTR  - CPE/handset

If you do have per customer it is still easy to identify the taffic
that need a header to be unwrapped if you are trying to avoid
unwrapping vpn traffic as you know the address of the AFTR boxes.

> >>=20
> >>=20
> >> >=20
> >> >>=20
> >> >=20
> >>today.=20
> >>=20
> >>=20
> >=20
> >> >=20
> >> >=20
> >>=20
> >--=20

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 8 Feb 2013 00:57:55 +0100

> From: Owen DeLong [mailto:[email-masked]]
> Sent: Thursday, February 07, 2013 8:36 PM
> To: Vízdal Aleš
> Cc: IPv6 Operations

Not really as pointed out by others already. The 10/8 or 100.64/10 address
spaces are not enough for some operators as some of them are facing the private
ipv4 address exhaustion already. IPv4-over-IPv6 and IPv6 can help here if they will
not need to hand out an IPv4 address to every single subscriber.

Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 8 Feb 2013 01:04:37 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv
> Asati (rajiva)
> Sent: Thursday, February 07, 2013 11:06 PM
> To: Jouni Korhonen; Owen DeLong
> Cc: IPv6 Operations

The Gi/SGi interface can be virtualised, but the impact is non-trivial i.e. may 
also need to virtualise all the nodes on the internet access path as these might 
be having issues with overlapping addressing, signalling could also be implacted.
It will also be operationally more complex.

Cheers,
Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Fri, 8 Feb 2013 01:12:06 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
> Andrews
> Sent: Thursday, February 07, 2013 11:35 PM
> To: Rajiv Asati (rajiva)
> Cc: IPv6 Operations

464xlat is not employing tunnelling or encapsulation (to my understanding) as there 
is only the IPv6 packet header, so the payload can be accessed by DPI, caching,
filtering if IPv6 aware.

Cheers,
Ales

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 8 Feb 2013 01:20:53 +0000

Yes,  /10 is what I meant to type, not /12. :)

Cheers,
Rajiv

Sent from my Phone

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 8 Feb 2013 01:30:51 +0000

Yup, no tunneling/encapsulation whatsoever. It is just an IPv6 traffic with L4= UDP/TCP as usual to the network.

Cheers,
Rajiv

Sent from my Phone

---

From: KAWASHIMA Masanobu <[email-masked]>
Date: Fri, 8 Feb 2013 11:19:39 +0900

Hi, Xing and All,

>published on June 13, 2009, earlier than June 26, 2009. 

Since some related applications(*) by China Mobile were applied 
on June 3, 2009, it is better to refer Section 5.2 "IVI NAT464" of 
draft-xli-behave-ivi-01, which is published on February 9, 2009. :-)

* http://worldwide.espacenet.com/publicationDetails/inpadocPatentFamily?CC=CN&NR=101931658A&KC=A&FT=D&ND=3&date=20101229&DB=worldwide.espacenet.com&locale=en_EP

Just for your reference, I would like to share the facts. 

- The patent CN200910085887(second on the list) was granted 
  on December 26, 2012. However, it applies only to China. 
  If you want to use 464XLAT in China, you may have to think over 
  whether the patent is valid or not. 

- Other related applications are still in the SIPO's examination 
  process. In other words, these applications are invalid as of now. 
  Moreover, scope of the application is only China and USA. 
  So it does not apply to other countries, that is to say, 
  draft-ietf-v6ops-464xlat has no IPR except China and USA. 

Regards,
Masanobu

>Vizdal Ales 蜀咎％:
>published on June 13, 2009, earlier than June 26, 2009.
>
>Regards,
>
>xing
>
>

====================================
 NEC AccessTechnica, Ltd.           
 Marketing Promotion Department and 
 Product Development Department     
 KAWASHIMA Masanobu                 
 [email-masked]           
 http://www.necat.co.jp/            
====================================

---

From: Maoke <[email-masked]>
Date: Fri, 8 Feb 2013 12:16:32 +0900

hi Masanobu-san and all,

thanks a lot for sharing the information. i have some add-ons for the
community as well.

2013/2/8 KAWASHIMA Masanobu <[email-masked]>

> *
> http://worldwide.espacenet.com/publicationDetails/inpadocPatentFamily?CC=CN&NR=101931658A&KC=A&FT=D&ND=3&date=20101229&DB=worldwide.espacenet.com&locale=en_EP
>
>

yes. the patent CN200910085887 was granted last December. however, to my
best knowledge, there were at least one early publication describing the
DNS-translation and NAT functionality for the IPv4-IPv6 NAT.

[1] Marc E. Fiuczynski , Vincent K. Lam , Brian N. Bershad , Marc E.
Fiuczynski , Vincent K. Lam , Brian N. Bershad, "The design and
implementation of an ipv6/ipv4 network address and protocol translator", in
Proceedings of USENIX Annual Technical Conference 1998, New Orleans, June
15-19 1998

we, as potentially using 464xlat in China, gently suppose the patent holder
doesn't incline to claim that their right solicitation includes the
DNS-translation and NAT64 functionality. if this is not true, we don't like
to but have to preserve the possibility of sending objections to SIPO,
asking for revoking the patent grant as it is claiming right over already
published knowledge.

>   draft-ietf-v6ops-464xlat has no IPR except China and USA.

again, also including the case regarding MAP-T, except the above
publication and the IETF docs listed by Masanobu and prof. Xing Li, we also
have the following early publications, already including the major
innovations of the work later becoming IVI, dIVI, and then MAP-T.

[2]  Maoke Chen, Xing Li, Ang Li and Yong Cui, "Forwarding IPv4 Traffic in
Pure IPv6 Backbone with Stateless Address Mapping," in Proceedings of 10th
IEEE/IFIP Network Operations and Management Symposium (NOMS 2006),
Vancouver, Canada, Apr. 3 - 7, 2006
[3] Yuncheng Zhu, Maoke Chen, Hong Zhang, Xing Li, “Stateless Mapping and
Multiplexing of IPv4 Addresses in Migration to IPv6 Internet,”. in
Proceedings of IEEE GLOBECOM 2008,  p.2248-2252, New Orleans, LA, USA, 30
November - 4 December 2008

for the same reason, we, the authors of the above publications, gently
suppose the patent applicant doesn't incline to claim their inventions
containing the right over the contents already published prior their
submission of the applications. if this is true, we expect the patent
applicant revoke their IPR claim in the IETF data-track. if this is not
true, we expect the patent applicant explain which part in the current
464xlat or in MAP-T, not covered by the above publications, but covered by
the patent applicant's applications or granted patent(s).

best regards,
maoke

---

From: KAWASHIMA Masanobu <[email-masked]>
Date: Fri, 8 Feb 2013 12:38:34 +0900

Hi Maoke-san,

Thank you for your additional information. 
I fully agree with you. There is no doubt. 

Regards,
Masanobu

>[3] Yuncheng Zhu, Maoke Chen, Hong Zhang, Xing Li, $B!#!<(BStateless Mapping and
>Multiplexing of IPv4 Addresses in Migration to IPv6 Internet,$B!#%"(B. in
>> >Vizdal Ales $B%O‚@%U!W!&(B:
>> >> Rajiv, Guys,
>> >>
>> >> <my_mobile_hat="on">
>> >>
>> >>