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

["Heatley, Nick" <[e-mail]>]

Dan, those options are costly, unsustainable in the long term, and drive customers away from the network.
It doesn't matter what helpdesk staff blame it on, what matters is that call has cost time and money.


-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Metzler, Dan J
Sent: 24 April 2015 14:33
To: Ted Lemon; George, Wes
Cc: Bjoern A. Zeeb; IPv6 Ops WG
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

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."  
If we really want to write a document, that states that IPv4 literals must not be used, shouldn't that be the first step?  Recognize the harm, and make a strong statement that IPv4 literals should/must not be used.
Why dance around these issues?  Seems to me that this is step 1.  The solution is to start by making that strong statement.  If we have tangible information about who has IPv4 literals, why not make that public?  Let people know where the problems are.
If the IETF can't bring itself to do this, then there is no need for this discussion, because it isn't really a problem, and we can all just turn off IPv4 today, or embrace it.

Only after addressing the above, (accepting that it is a problem), is it time to look at what to do in the meantime as a work around.  
Dual stack is a certainly solution if people aren't ready to move to IPv6-only.  It gets around the IPv4 literal problem by simply maintaining support for IPv4 while it's needed.

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


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.

- Dan Metzler

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

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops
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.