Re: Mutli6 meeting in Vienna

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Sean;

> > Remember that the first version was taken seriously by you and
> > Harald.
> 
> And me.

Oh, yes. Thank you and several others.

> However, two things stand out:
> 
> (i) I made a number of comments and asked some questions
>      on the list after having read through your draft; and
> 
> (ii) The draft is old and needs a refresh.
> 
> I wonder if you could be persuaded to submit a new revision
> in light of these two points?

Yes, of course.

In addition, I answer your questions in this mail (as, in your
mail, they are located after an lengthy discussion and summary
of my draft, I have overlooked to answer them) in this mail.

>     How does a host know its address?
> 
>     That is, how does a host learn what set of path-indicators
> _can_ (not should, can) be advertised during the initial
> handshaking of a new TCP connection (or thereafter)?

Your question should be about a set of addresses of its own, not
peer's.

Then, my assumption is, they is preconfigured, just as addresses
of hosts today, by hand or through DHCP. You can also say RA,
though I think it sucks. A more smart solution is to let IGPs
carry them.

After the initial hand shaking, mobility may modify the set.

>         How many path-indicators should MultihomedSender
>         announce to the Receiver?  Two?  More than two?
>         How many path-indicators will Receiver announce
>         back in reply to the Sender's SYN (which uses a
>         path-indicator from the DNS)?  

There should be reasonable maximum. Currently, we set it 8.

Please don't assume that we can't modify TCP, or its maximum
option length.

>         Next: change.  What happens on the host if
>         MultihomedSite multihomes to another network?
>         What happens if some time (days?) subsequently
>         MultihomedSite permanently disconnects from
>         LocalISPNumberOne?  If the answer is: the host
>         acquires via some protocol (or manual
>         configuration) a new path-indicator, who assigned
>         the path-indicator in the first place?

Upper level ISPs assign the path-indicator, which will be hand
configured to hosts, DHCP servers and, most importantly, DNS
servers.

Please don't say "automatic renumbering", which is known to
be impossible w.r.t. DNS entries.

>         Incidentally, any solution to this which does not
>         require changes to the current routing system is
>         also a general solution to site renumbering, which
>         is much-missed feature in IPv4 and IPv6, and
>         likely would be worthy of an RFC of its own.

As I wrote:

   However, to enable source address filtering to discard packets with
   source addresses not belonging to an ISP, it is useful to enable a
   host, not some intelligent intermediate router, select a source
   address compatible with an outgoing ISP.  For that purpose, intra
   domain routing protocols should maintain routing table entries with
   not only preference values of an external routes, but also proper
   prefixes to be selected for source addresses, if the entries are
   chosen by a host.

I don't preclude the possibility to change the current routing
system, though, in this case, it is entirely optional and you can
do it by hand.

But, remember that the impossible part of automatic renumering
is in DNS.

						Masataka Ohta