Subject: RE: survivability, rewriting

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Nov 2003 10:58:46 +0100 (CET)

> > 1. The ULPs need to know the addresses of the node itself to be able
> >    to perform certain forms of referal. But that doesn't prevent
> >    the node to issue IP packets with a source locator that doesn't
> >    include the upper bits of the address *as long as* the host knows
> >    that there is a rewriting router along the path.
> >
> I am sorry, Erik, but i don't understand this argument.
> Those rewritable addresses wouldn't be passed for referrals purposes, they
> are just an artifact to let the M6 layer to notify the border router that
> they should complete with a real prefix. The application would only be aware
> of the AID. The referals would contain real locators. I guess i am missing
> your point here :-(

I guess I wasn't very clear - there are two separate issues mixed together.

One could allocate a prefix, such a 0::/48 if you ignore that
there is some other use for that, for use as the source locator.
Thus the host could send packets with that source *IF* it knows that there
is a rewriting router in the path which will insert the correct
high-order bits in the source locator.
But this is tricky to migrate to since the host would need to be able
to tell whether its site has such rewriting routers at the boundary;
if the 0::/48 makes it to a remote peer it will not be able to respond.
How can it do this?
Having the source send packets with the actual source locator prefix
plus indicating that it is ok to rewrite it doesn't have this issue;
if there is no rewriting router in the path the source locator
stays unmodified but it still usable for the peer to respond.

Second part is just the observation that having the node send packets with
a fixed source prefix (such as 0::/48) doesn't remove the need for
the ULP/apps to know the actual source locator, since it might need
this as part of referals.

   Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 3 Nov 2003 15:05:24 +0100

> if the 0::/48 makes it to a remote peer it will not be able to respond.

I guess that if a host has the M6 mechanism working, it would be reasonable
to assume that the site supports M6 and so that exit routers would rewrite
the source address.
But anyway you could also use a bit in the router advertisement to
communicate it to the hosts, right?

> this as part of referals.

Agree but why this a problem? If i undestand correclty, Iljistch just
wanted:

"The obvious place to put an indication that the address may
 be rewritten is... in the address. "

I don't see why the second part is conflicting with Iljistch goal...

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Nov 2003 17:28:02 +0100 (CET)

> to assume that the site supports M6 and so that exit routers would rewrite

How so?
If we decide to standardize something which goes in the stack
then it will hopefully appear in future versions of various stack
implementations asynchonously and hosts with those new versions will appear in
an uncoordinated way in various parts of the network.
Thus you can't assume that somehow the site network admin is
in charge of what OS/stack version is installed on all the hosts
in their site.

> communicate it to the hosts, right?

Yes, but you also need a way to get this information into all the routers
in the site. If the router renumbering RFC was widely implemented and used
it would provide a mechanism on which to add such additional information,
but that protocol doesn't seem to be implemented much.

My point is that if there are mechanisms which do not require such 
coordination between the site border routers and the hosts in the site
they are preferable (all other things being equal) since this coordination
is additional complexity i.e. additional places where things can go wrong.

> I don't see why the second part is conflicting with Iljistch goal...

It doesn't, which is why I called it "an observation" in the clarification.

  Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 3 Nov 2003 20:15:57 +0100

> in charge of what OS/stack version is installed on all the hosts

No, but the mechanism doesn't have to be on by default, i guess.
I mean, the same problem would happen if you place host in a single homed
site and that you have configured multiple IPs for whatever reason.
In this case you don't want that the host starts using M6 mechanism, just
becuase it has multiple IPs configured.
So M6 is off by default (to ensure compatibility with single homed sites)
and it is turned on by the admin, who should do it if the site is multihomed
and routers are capable of rewriting packets.

> is additional complexity i.e. additional places where things can go wrong.
Agree...
So you would need a mechanism to discover that the host is in a multihomed
site, right?

> It doesn't, which is why I called it "an observation" in the

Ok

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Nov 2003 11:16:57 +0100 (CET)

> becuase it has multiple IPs configured.

Why would you have multiple IP addresses configured and you don't want
to use them for multihoming?

> and routers are capable of rewriting packets.

Why does it have to be off by default? Nothing would break if it is turned
on if the hosts use some information from the DNS lookup to determine
whether the peer supports multi6.

> So you would need a mechanism to discover that the host is in a multihomed

I haven't seen why this would be required.

In fact you want multi6 capable hosts to invoke the multi6 mechanisms
because the peer might be multi6 capable.

   Erik