(sipp) re: SST overview paper

[Bob Gilligan <[e-mail]>]

>  > From: [e-mail] (Bob Gilligan)
> > As promised, I have written up an overview paper explaining the Simple
> > SIPP Transition (SST) proposal.  I'll send this in to the internet
> > drafts editor today so that it can be entered into the archives before
> > the Toronto meeting.  Send comments, questions or suggestions to me or
> > the list.  We can discuss SST more at the SIPP working group meeting
> > in Toronto.
> >
> As I have already indicated a number of suggestions to Bob that were not
> incorporated, I will write up something of my own in the next couple of
> days.  I tried explaning what I was looking for, but sometimes it's just
> faster to write the whole thing yourself.
> 
> I was especially unhappy with the 2 "flag days":
> 
>  1) when IP addresses run out, new SIPP/IPv4 nodes can't continue to
>     talk with old IPv4 nodes in the same commonwealth.  This was a
>     cornerstone of IPAE that I am unhappy to see disappear.  But, I can
>     live with that, as it provides an incentive for upgrading, I guess.

I don't see any reason why SIPP/IPv4 nodes should not be able
interoperate with IPv4-only nodes within a limited scope after IPv4
addresses run out (if they run out).  As long as there is some part of
the IPv4 address space that can be re-used in different sites, you can
continue to install new IPv4-only or SIPP/IPv4 hosts and have them
interoperate with the rest of the IPv4-only hosts in that site.

>  2) when SIPP-only hosts show up in an area, you have to TURN OFF IPv4
>     routing.  This is totally unacceptable to me.

Actually, the restriction is that you must convert an area to
SIPP-only before you can install SIPP-only hosts.  And to convert an
area to SIPP-only, you must turn off IPv4 routing within that area.
So, the ordering of events would be:

  1)	Convert all hosts and routers within area to SIPP/IPv4.
  2)	Turn off IPv4 routing within the area.
  3)	Install SIPP-only hosts in area.

Note that IPv4 routing is not needed within SIPP-only areas because
such areas, by definition, have no IPv4-only hosts.

The requirement to turn off IPv4 routing is included primarily so that
SIPP/IPv4 hosts deployed in SIPP-only areas don't try to send IPv4
packets over the remnants of an IPv4 topology that doesn't go
anywhere.  If this restriction turns out to be too severe, we could
probably eliminate it by just configuring the SIPP/IPv4 hosts not to
use IPv4.

> Of course, there are other problems, such as:
> 
>  - SIPP/IPv4 routing should be a combination, with interoperation, but
>    instead means IPv4 routing with SIPP encapsulation.

I'm not sure I understand the question here.  There is one fundamental
constraint in designing the routing areas: You can't mix IPv4-only and
SIPP-only routing topologies without placing a translating router
between the two.

>  - translators have to be specially deployed at SIPP boundaries, and
>    need lots of configuration.  Blech.

Actually, there is nothing to prevent one from deploying translating
routers in the interior of an area.  However, it is not required.

The only configuration that translating routers need is to know which
packets need to be translated, and which should be simply forwarded
unchanged.  This configuration information is local, not global.  That
is, translating routers need to know which address prefixes are used
in the areas that they are directly attached to. Perhaps this
configuration information could be derived from routing information.
I haven't thought that through.  Someone might want to propose
something here.

>  - SIPP-only says it "does not understand IPv4", but in reality will
>    continue to support A DNS records, a special checksum calculation,
>    FTP PORT commands, and who knows what else IPv4 stuff.  I think
>    SIPP/IPv4 should support both, and SIPP-only just don't talk IPv4,
>    even through translators.

I don't think that we are outlawing a "true SIPP-only" host that would
not have the IPv4-compatible checksum and A record support.  However,
such a host would not be able to interoperate with IPv4-only hosts,
even with the help of a translator.  Since the objective of the
"transition mechanisms" are to provide interoperability with IPv4-only
hosts, I think that a "true SIPP-only" host is really outside the
scope of the transition spec.

>  - I don't expect to see SIPP-only for 20 years, and so much of this
>    draft is irrelevant, particularly the ::1 prefix.  Several others
>    have stated this, too.

It may be true that SIPP-only areas are a long way off.  However, that
doesn't mean that the ::1 prefix is not needed.  We need the two fixed
prefixes (::0 and ::1) so that SIPP/IPv4 nodes can determine which
packets can be sent as SIPP encapsulated within IPv4, and which must
be sent as "raw" IPv4.  Since the prefix encodes whether the node is
an IPv4-only node or a SIPP node, the "SIPP layer" can determine which
packet format to send simply by looking at the prefix of the
destination address of the packet it is sending.

>  - I think the topology is wrong.  We won't see islands of SIPP-only,
>    we'll see islands of IPv4-only.  That requires a thought experiment.
>    I'll just write it out in my draft.

Clearly we will see lots of islands of IPv4-only for quite some time.
Islands of SIPP-only will come about only if the design allows it!

Bob.
 ------------------------------------------------------------------------------
IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to [e-mail]