[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ocean: do not boil



Margaret,

The piece that I think your missing is pretty simple really.  The customer does not want a parallel IPv4 infrastructure and wants it removed as soon as possible.  It only wants to permit access to IPv4 in a temporary mode or through NAT ( that will be the two customer choices).  But to say we know best about this is not wise.  We don't have a clue.

/jim

> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: Tuesday, September 24, 2002 12:09 PM
> To: Hesham Soliman (EAB)
> Cc: Hesham Soliman (EAB); 'Brian E Carpenter'; Hesham Soliman (EAB);
> 'Bob Hinden'; Randy Bush; Bob Fink; Jun-ichiro itojun Hagino;
> v6ops@ops.ietf.org
> Subject: RE: ocean: do not boil
> 
> 
> 
> Hi Hesham,
> 
> >=> 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.  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.
> 
> >   > We can suggest any one of these solutions, and people are,
> >   > of course,
> >   > entitled to ignore us.  Given the choice between these
> >   > three, though,
> >   > the third one seems simpler
> >
> >=> 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
> translation.
> 
> 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.
> 
> >and less prone to introducing new
> >   > architectural and application-level issues,
> >
> >=> 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
> >up.
> 
> 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?
> 
> Margaret
> 
>   
> 
> 
>