[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft for Translator discussion
Miyata,
To be clear I'm actually in favour of 2766, and not a big fan of 4966.
4966 seems like cutting off the nose to spite the face, to me. But I
wasn't participating in the IETF when all this was decided so I can't
really comment.
Maybe I'm just too naive or just not smart enough, but I'm
contemplating the start of a future endgame where I begin to turn off
IPv4 networks inside my company one at a time. I'll need dual stack
for a long time but once I've got IPv6 broadly available then I should
be able to start examining networks and the applications my users are
hitting and identify subnets that have no real need for IPv4 anymore
(as long as something like NAT-PT is in place).
I'm imagining these would be the sort of corporate networks where the
traffic is principally HTTP, maybe some CIFS/NFS, and perhaps some
SMTP. Heck even ssh traffic would work just fine on an IPv6-only
network (with some extra known_hosts key accepting). For these users'
traffic 2766 is basically OK. Perhaps I just haven't run into
something that will make me see sense, but it seems the needs are
pretty simple for us. Again: perhaps our needs are degenerately
simple or perhaps my thinking is degenerately simple.
Of course if I run into problems described in 4966 (or not mentioned
there, for that matter) I have a line of defense lots of people may
not have: I get to ask "Is there a legitimate business need for this
to work?" (the old "defer to higher authority" negotiation tactic)
Let me say though that any solution that involves an update to the
IPv6 stack *on the hosts* is not a solution for me (I *fully respect*
that it may well be wonderful for other users, networks, applications,
or purposes and could deserve considerable attention from the WG). My
host IPv6 stacks are deployed (it's just the routing isn't all there
yet, and perhaps IPv6 is disabled administratively). I don't want to
have to upgrade my entire fleet of VendorOS desktops and servers to
get the lastest shim/nat-aware ipv6 stack. I want to buy a device. I
already have (or will eventually :-) a bunch of IPv6-capable hosts; I
just want to buy something to stick between them and the IPv4 world
until it's safe to let it die (in 10 years time, or whenever).
I've probably wandered well off topic and much of what I've said may
utterly lack relevance so I'll stop now.
Thanks,
-Erik
On 12/5/07, Hiroshi MIYATA <miyata@tahi.org> wrote:
> Erik,
>
> Thanks, for your comment.
>
> I can agree deprecating NAT-PT since it is fully combined with
> controversial DNS-ALG.
>
> I think there would be some translation solutions, depending on the
> requirement.
> So some portion of NAT-PT works well in some limited environment.
>
> Then it is one of the approaches to sprit apart NAT-PT and pickup
> some portion
> and give some simple modification if required.
> Of course adding some notification what is the advantage/disadvantage,
> recommended usage/unrecommended usage.
>
> ....miyata
>
>
>
> On 2007/12/06, at 14:18, Erik Kline wrote:
>
> > On 12/5/07, Hiroshi MIYATA <miyata@tahi.org> wrote:
> >> Hi all,
> >>
> >> Now we have big wave of translator discussion.
> >> As RFC4966 deprecated NAT-PT, it is good thing to discuss on
> >> alternatives.
> >>
> >> On the other hand, I have some concerns.
> >>
> >> a) Time frame.
> >> 2010 is very close.
> >> Short term view is desired by the market as well as long
> >> term view.
> >>
> >> b) Target devices.
> >> It is good thing to design translation technologies to
> >> resolve
> >> all issues listed in RFC4966.
> >> Some translator proposals require modification to IPv6 end-
> >> devices.
> >> But we have to be aware that we already have many IPv6
> >> devices
> >> deployed.
> >>
> >> So, we should take care of following kind of devices.
> >> - IPv4 devices
> >> - Existing IPv6 devices
> >> These does not have special code to work with
> >> translator.
> >> - Future IPv6 devices
> >> These has special code to work with translator.
> >>
> >> To prepare the coming IPv6 deployment, we need to clarify what is
> >> required for
> >> which kind of device by when.
> >>
> >> To ask your opinion, I described my concern briefly.(just as the
> >> first step)
> >> When we consider the tranlator, this kind of document itself is also
> >> required not to
> >> produce the missing part, I think.
> >>
> >> http://www.tahi.org/~miyata/doc/draft-miyata-v6ops-trans-
> >> approach-00.txt
> >> (I submitted it to IETF)
> >>
> >> Please take a glance and give your comments. It is very short one.
> >>
> >> Thanks,
> >>
> >> ....miyata
> >>
> >>
> >
> > I'm sure I'll be derided for eternity and my eat my words, but at the
> > moment it looks like the old NAT-PT (2766, iirc) works just fine for
> > my deployment/transition needs (for IPv6-only corporate networks).
> > None of the objections in 4966 actually apply in my situation. I may
> > be the only one, but I intend to keep using the deprecated method
> > until I have to change. Perhaps my company is degenerately simple,
> > but I'm fairly sure I can reap IPv4 networks (once I've achieved wide
> > dual-stack deployment and healthy IPv6 transit, etc.). Of course
> > there are Operating System *platform* issues (like why do I have run
> > DHCPv4 for certain OSes if I'm trying to run an IPv6-only network?).
> >
> > -Erik
> >
>
>