[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ocean: do not boil
- To: "'Margaret Wasserman'" <firstname.lastname@example.org>, "Hesham Soliman (EAB)" <email@example.com>
- Subject: RE: ocean: do not boil
- From: "Hesham Soliman (EAB)" <firstname.lastname@example.org>
- Date: Tue, 24 Sep 2002 20:36:32 +0200
- Cc: "Hesham Soliman (EAB)" <email@example.com>, "'Brian E Carpenter'" <firstname.lastname@example.org>, "Hesham Soliman (EAB)" <email@example.com>, "'Bob Hinden'" <hinden@IPRG.nokia.com>, Randy Bush <firstname.lastname@example.org>, Bob Fink <email@example.com>, Jun-ichiro itojun Hagino <firstname.lastname@example.org>, email@example.com
- Delivery-date: Tue, 24 Sep 2002 11:37:36 -0700
- Envelope-to: firstname.lastname@example.org
> >=> I'm not trying to be -ve,
> I'm not sure what "-ve" means, but I'm certain that you
> aren't trying to be it :-).
> >but unless we mandate
> >that all applications will use this model, or alternatively
> >assume that HTTP and SMTP are the only important applications
> >for the medium term there is no point eliminating the
> >v6 -> v4 scenarios.
> Which model? All widely deployed IPv4 applications work with
> the existing IPv4 model.
=> see below.
If that model continues to be the way
> to reach IPv4 services (as I have suggested), there wouldn't
> be any need to change existing IPv4 services.
> >Clearly (at least to me), it would be pointless to start
> >making "recommendation for application layer protocol
> >developers" in this group. This _is_ boiling the
> >ocean IMHO.
> I agree. Requiring a application-layer proxy for each type
> of application is not desirable.
=> ok, that's what I was referring too above ("the model"
suggested in an earlier email)
> >=> Can you please explain why it is "simpler" ?
> In my opinion, the use of parallel IPv4 and IPv6 infrastructure
> is simpler than IPv4<->IPv6 translation, because it doesn't
> require special support from the DNS system (either servers or
> resolvers), doesn't require injection of routes for special
> IPv6 address prefixes, and doesn't, inherently, require any
=> Depending on the solution you choose there might
not be any special addresses or special routing.
In fact, regardless of the model you choose I don't
see the need for any special routing. Translation
is already there, whether it's a v4 NAT or a NAT-PT.
The scalability issue is also there regardless.
What you mention about the DNS issues is valid, but
this kind of "simplicity" (of removing the DNS issues)
is not necessarily operationally simpler when compared
to running IPv4 NATs. Any operator can jump in about
now and tell us what they think.
> Now, it is true that the IPv4 infrastructure may include a
> NAT. But, even in those cases, the parallel use of IPv4 avoids
> complexity in the DNS and routing tables.
=> I don't understand what complexity is there with
the routing tables.
> >=> What does this mean?`what architectural issues
> >are reduced by v4 NATs?
> The use of parallel IPv4 and IPv6 infrastructure, even with
> the use of IPv4 NATs, does not introduce any _new_
> architectural issues. Yes, there are some major architectural
> issues with IPv4 NATs, but these issues are not new, and IPv4
> applications have already been modified/limited to work within
> this type of environment.
> >since the IPv4
> > > infrastructure
> > > would be exactly the same as what many people are using today.
> >=> Margaret, please consider my concern: I am not talking
> >about networks with _existing_ IPv4 infrastructures/NATs.
> >I hope my intention is clear. I know that many ISPs
> >already have v4 NATs and this is not the case I'm bringing
> Yes, I understand this, Hesham.
> But, I really do think that it would be wiser for a networ
> operator to install parallel IPv4 and IPv6 infrastructure in a
> new installation, if any of the nodes on their network will
> need to access IPv4-only services.
> Installing an IPv4 NAT and DHCP server won't be any harder than
> installing a v4<->v6 translator with DNS and routing tie-ins. You
> won't need any more IPv4 addresses than you do in a v4<->v6
> translation model (you will always need a v4 address to access
> a v4 service), and using a "normal" (by today's standards)
> IPv4 infrastructure will result in fewer problems accessing
> IPv4 applications and services.
> What am I missing?
=> I don't exactly think one of us is missing
something (except that I don't think there are
any routing issues here, unless running a dual
network involves more management of the routing
infrastructure). I think the issue here is a matter
of assumptions. You assume that it's ok to tell a
new operator in china or anywhere that to deploy
their new IPv6 network they need to buy and run
an IPv4 private network (well, buy the NATs anyway). I assume
that they would rather not do that and that this extra
infrastructure is redundant.
I also think that simplicities you mention (regarding
the DNS)are simpler for us (IETF people), but I'm not
sure that operationally it will be simpler for people
to buy and run a dual network, especially when they
don't need it.
I'm not pushing for NAT-PT/SIIT deployment everywhere,
but my preferences for a new operator are:
1. Run a dual stack network with public addresses
2. If public addresses are not possible (for v4)
then just run a v6 network.
PS: I think this discussion is a proof that we
need to get more operators involved and more
discussions before we eliminate anything.