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

["Metzler, Dan J" <[e-mail]>]

Nick, see responses inline.

> -----Original Message-----
> From: Heatley, Nick [mailto:[e-mail]]
> Sent: Friday, April 24, 2015 9:28 AM
> To: Metzler, Dan J; 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
> 
> Dan, those options are costly, unsustainable in the long term, and drive
> customers away from the network.
[DJM] 
Can you be more specific?  Which options are costly, and unsustainable? 
Given that I think I stated every possible option, I recognize that options can be costly, some more than others.  Never-the-less, those are the options available to us, so we are all going to pick one or more of them regardless, right?


> It doesn't matter what helpdesk staff blame it on, what matters is that call has
> cost time and money.
[DJM] 
I'm more focused on "cause" than on "blame", but not only does it matter, it is critical.  It determines where, and whether, efforts will be focused on actually solving the problem or not.  What matters most is the willingness to accept and identify the "cause" of the problem.  If there is a refusal to address the cause, then the problem will not get fixed, and will simply become more costly on a broader and broader scale, as everyone else is forced to absorb the cost of workarounds or inaction.  

That call is going to come into the helpdesk regardless.  Whether that is the last call, or the start of many more, depends entirely on what the response is, and whether it includes actions that address the cause of the issue or not.

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