John C Klensin wrote:
--On Thursday, 17 April, 2008 08:19 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
Arnt Gulbrandsen wrote:
I'm willing to take that on, unless anyone minds.
Arnt
If you wish help, I would be willing to pencil in the time.
I did begin last week an outline that I can pass on with
collected research of past work and industry experiences and
presentations highlight the major concerns and technical
issues with the current proposals.
I personally would like to suggest that this BCP be a guide to
help multiple audiences with a smooth transition to Ipv6
- DNS Administration
- System implementor/integrators, network engineers
- Software Developers
- Operators
- End Users
Hector, fwiw, despite the pattern in some desktop systems to
require that everyone and their grandmother have the skills of
system and network administrators, I suggest that path is
ultimately a failure. As a result, I believe that if end users
need to worry about what is happening at the Internet layer and
how to adjust to it, it would be a sign that all of the other
layers and actors in this process have failed. I would rather
concentrate on not failing than on trying to inform end users --
people who see the mail system only through the MUAs or web
interfaces they use and the error messages they receive -- about
what is going on here.
There might be need for what the IETF used to call an FYI RFC to
explain some of the disconnects and the messages they cause to
those end users, but I'd think the entire effort would progress
better and more efficiently if they were kept separate.
john
I Agree.
The inclusion of end-users was more for responsible parties/implementers
to gain insight on what impact it has on their user base and how they
may better address it when you begin to consider IPv6. For example:
- how will this alter POP B4 SMTP Methods which is a very big part
of reducing help desk support cost for many cost conscious ISPs.
and thats just one of many questions related to end-user impact.
As you would probably agree, such insight will help people prepare
information they might need for their users and company. I didn't want
to dig more into that other than throw out the coverage.
It is my opinion if one goal here to we help the industry migration,
then at this point we need to take our blinders off and understand not
everyone is at the same level as the early explorers. I don't need
lacking direct IPv6 experience forfeits or trump long time engineering
insights and planning. This is highly complex stuff and I believe it
will take us to do a good job in presenting a clear consolidated
documentation on how to get from point A to AB to B.
Just ask these fundamentals questions:
- How do you get an IPv6 address(es)?
- How do you implement it?
- What's the relative cost impact? No specifics, but cost is no doubt
going to be a prohibiting factor for many. This might suggest IPv4
might not go away for a lot longer than anyone here thinks.
- Can you lose IPv4 addresses once you request your IPv6 allocation?
Again, not a political question, but how that alter your plans for FULL
or HYBRID IPv6 hosting services?
- Do you need extra software besides getting your SMTP vendor to support
IPv6?
- Will you need to switch SMTP vendor?
- Do you need to upgrade to new (hardware) routers?
- Do you need to write anything yourself?
- How do we handle users?
- Do you need to have separate processes running, IPv4 and IPv6 as
suggested by one of the RFCs?
- Or will it work just fine as a single process IPv4/6 hybrid?
- What is 6to4? Is that part of the total implementation?
- Can I use just IPv6 and depend on my uplink offering a dual stack gateway?
Oh gosh, a whole slew of general questions, and I am not saying all of
this needs to be addressed but to rather bring it out all so we can get
a better picture of what are all the issues to create the focused document.
I mean, I think we just touch based with just a part of it:
- How does the IPv6 stack change the security picture?
- How does all the new "Features" of IPv6 change SMTP mail distribution?
- Is "PTR" lookup a viable idea? Is it necessary now?
- Can systems need to do a CBV or can they stop doing return path
verification and begin using the inherent IPv6 stack IP connectivity
information? Ethernet tracking/tracing?
- Do we need new SMTP EHLO extensions? Can a new extension help with an
orderly migration?
- How does it change any other SMTP related extension?
- What effect will it have on such technology as:
- SPF, SENDERID?
- DKIM, DOMAINKEYS?
- SpamAssassin?
- Sieve?
- Some people have already suggested that getaddrinfo() be patched to
remove redundancy in AAAA lookups? Is this a valid issue to address?
How does that change the RFC 3484 recommendations?
- Is there any change in TCP timeouts? Does IPv6 stack goes idle? Do
we need to change state machine timeouts?
and I haven't even begun to outline the concerns I have at the coding
area and how IPv6 can change the SMTP model as a first in where IPv6
dictates implementation methods, i.e. how discovery is implemented with
getaddrinfo(). Can this "document" be written and described where its
doesn't need to be locked in stone with a socket level 2 API function?
Again, the above is just a small list of questions I think that should
be on the table, some are very important, some can be kick out, and I'm
sure there are others that have better questions that is more focused
with their own experiences and noticed I didn't even bother to bring up
the IMPLICIT MX issue but no doubt that would be a part of all this.
I just think the IETF can do a better job to promote this type of
consolidated work to help with the desire to move people to the IPv6
world at a more reasonable and understood manner rather than just hope
it will take place on a wing and prayer with mixed information.
On a personal level, we have a Class C group of IPv4 addresses, and I
don't even know all that is needed or that I could even move into IPv6
without getting other entities involved, like my ISP uplink, MCI/UUNET
now own by Verizon. I need to find out is CISCO has updates for my
router or are they going to force a hardware change. Of course, the
specifics like this is not what we want to write, but maybe how the
general situation applies in IPv6/4 implementation.
And of course, finally, we will need wisdom from people like you to help
keeping it all focused.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com