Re: IPv4 depletion makes CNN

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

 



In message <EEF83942-7B6D-4169-A7E2-F51306182620@xxxxxxxxx>, =?iso-8859-1?Q?Pat
rik_F=E4ltstr=F6m?= writes:
> On 31 maj 2010, at 03.39, Mark Andrews wrote:
> 
> > And have any of those that say this tried:
> > 
> > 	1) tried dual stack
> > 	2) tried IPv6 only through NAT64 (NAT-PT)
> > 
> > with a sample of customers or are they just talking without any
> > reference points.
> 
> I am spending lots of my time trying to get some _real_data_, but I do 
> not have it yet.
> 
> I am though running dual stack with native IPv4 and native IPv6 in my 
> home office, on all my servers, and have quite some experience on dual 
> stack. And that was not as fun as I expected.
> 
> I.e. my data is based on dual stack be worse than I expected, and having 
> people asking me "would native IPv6 only be better", or "what about 
> native IPv6 with NAT64/DNS64".
> 
> And I have also read various papers people in IETF have written on how 
> to handle the quite normal case with SMTP where MX records are in use 
> (which have been far from complete), and then maybe IP6 or IPv4, and 
> IPv6 or IPv4 for DNS transport, and quite often search paths in DNS as 
> well... The number of DNS lookups needed explode exponentially, you get 
> timeouts on application layer, applications show timeout boxes as if the 
> mail server is not responding when in reality multiple seconds are used 
> for DNS lookups.

MTAs should never search.  MX records are absolute (explict or
implicit).

MSAs should only search to qualify unqualified domains in user
submitted data.

Just curious.  What percentage addresses in your address book are
not fully qualified.  I know I gave up on unqualified address back
in the early '90s.  Also are all the search element served locally
or do you need to do a remote lookup for them?

And it shouldn't be exponential growth.  Double maybe.

> It is messy with dual stack. Messier than what I think many people 
> think. Including me (and I thought I had quite good overview of how it 
> worked).
>
> > Runing dual stack internally without external IPv4 connectivity is
> > just as bad as running dual stack internally without external IPv6
> > connectivity.  You just don't want to go down that path.
> 
> I claim it is worse than having IPv6 only.
> 
> > Yes.  I've tried to run IPv6 only.  Real IPv6 only, IPv4 completely
> > disabled in the OS.  It wasn't fun.
> 
> So have I. For example at the IETF in Anaheim one morning when IPv4 
> connectivity was broken.
> 
> For me it worked better than dual stack, when accessing things that was 
> reachable over IPv6. But that was with my OS (MacOSX) that have 
> relatively good IPv6 support.

And problems with its resolver trying to be too smart. :-)

> So there are good things and bad things with both dual stack and IPv6 
> only. And no, we do not have any data, but we do not have good documents 
> on how to run dual stack either.
> 
>    Patrik
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@xxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]