Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

["Howard, Lee" <[e-mail]>]

On 4/24/15, 9:33 AM, "Metzler, Dan J" <[e-mail]> wrote:

>See below
>
>> -----Original Message-----
>> From: v6ops [mailto:[e-mail]] On Behalf Of Ted Lemon
>> Sent: Wednesday, April 22, 2015 9:38 AM
>> To: George, Wes
>> Cc: Bjoern A. Zeeb; IPv6 Ops WG
>> Subject: Re: [v6ops] The need for local-ipv4 socket transition
>>solutions --
>> NAT64/DNS64 remains insufficient
>>
>> On Apr 22, 2015, at 10:33 AM, George, Wes <[e-mail]>
>> wrote:
>> > WG] Should we be trying to raise visibility on this issue in other
>>forums?
>> > For instance, IETF has a formal liaison relationship with W3C. Perhaps
>> > an effort there would be useful, even if it doesn't necessarily cover
>> > non-web app developers?
>>
>> I am skeptical that the people who are using IPv4 literals are active
>>in any
>> standards community.   I suppose it's possible, and reaching out and
>>getting
>> e.g. W3C to make a strong statement about this would certainly be good
>>in the
>> sense that it might shorten the long tail, but I don't think it's going
>>to fix the
>> problem soon enough.   I really can't see any way to address this that
>>doesn't
>> look something like 464xlat or IPv4-as-a-service (e.g. softwire
>>MAP/lw4over6).
>
>[DJM]
>I see one common theme in this discussion:  "IPv4 literals are harmful."

I think I read consensus on that statement.
I'm not sure there is consensus that the IETF is the right place to make
such a statement. There might be; I think we need a document to discuss to
see if there is consensus.
Somebody needs to write it for us to discuss it. Hint, hint.


>
>So then what if you don't have the IPv4 address space, or you can't do
>dual stack?  Well you have 4 options, depending on your situation:
>1) Go buy more IPv4 address space.  Ok, maybe that's going to be costly,
>but I think we knew that was going to happen.  If you need it, then you
>need it.  (If you are one of those who suggest that IPv4 will always be
>there, then do this and embrace your future now.)
>
>2) Use 464xlat or IPv4 as a service, and just realize that not everything
>has support for that.  When customers call to complain, don't blame the
>vendor who won't support your technology of choice.  Place the blame on
>those using IPv4 literals, where it belongs, and point out that there is
>a document that states it is wrong to implement IPv4 literals; (because
>IETF took the first step as mentioned above.)
>
>3) Maybe not everything on your network really needs to talk IPv4.  Shift
>some of your network to IPv6 only, and move the addresses around, to buy
>time.  If IPv6-only customers call to complain, place the blame on those
>using IPv4 literals, where it belongs, and point out that there is a
>document that states it is wrong to implement IPv4 literals; (because
>IETF took the first step as mentioned above.)
>
>4) Ignore the issue, and treat it as insignificant.  When customers call
>to complain, place the blame on those using IPv4 literals, where it
>belongs, and point out that there is a document that states it is wrong
>to implement IPv4 literals; (because IETF took the first step as
>mentioned above.)

I don't know whether all of this needs to be in the draft. The note that
one person's use of bad practices means others have to decide whether and
how to deal with it is worthwhile.

>
>
>If however, a WG and the IETF cannot be bothered to make the statement
>that IPv4 literals are bad, then it follows that IETF really would be
>saying that IPv4 literals are not a problem.  It would suggest that IETF
>is not really committed to IPv6-only, and that the plan is to try to
>scale IPv4 to suit the needs of tomorrow.  My personal opinion is, I
>think that would be irresponsible, but I'm starting to wonder if that's
>really where things stand for some.

That's back to the question of whether the IETF is the right place to say
something. It might be that we believe this is more appropriate somewhere
else.

Lee


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.