Subject: Re: updating GSE for the new millennium

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 1 May 2003 10:32:56 +0200

On donderdag, mei 1, 2003, at 02:45 Europe/Amsterdam, David Conrad 
wrote:

>> We've been talking about GSE earlier this month before we got 
>> side-tracked. I think it's time to see what a descendent of the GSE 
>> family would look like in the third millennium, so I want to write a 
>> draft. Hopefully this will give us something useful to talk about in 
>> Vienna.

> Hmm.  I am doing the same thing (although I'm not planning on being in 
> Vienna).

Ok. It's going to be interesting to see the differences in two drafts 
based on the same approach.

>> What I'd like to do is take input from everyone and incorporate this 
>> as much as possible in this draft. That probably means more options 
>> and more complexity that we'd like to see in an actual protocol, but 
>> for now that's fine: we can always prune later.

> I would suggest starting the other direction -- the IETF already has 
> way too many drafts that try to be all things to all people.  Start 
> with a simple, easily understood base and see how far that gets you.

I hear you, but I'd still like to err on the side of including too 
much. If nothing else, this makes the discussion easier and we can 
always remove it later.

> Depending on your approach, it may not be necessary to rewrite the 
> source address.

Ok, two problems then:

1. ISPs do ingress filtering towards their customers so those can't 
spoof their source addresses. This is something we don't want to break 
if we can avoid it.

2. This makes sending back ICMP errors much more difficult because the 
routers along the way then need to support this solution. Note that 
dropping ICMPs is not an option because PMTUd is mandatory for stuff 
handling packets bigger than 1280 bytes.

>> For the source when transmitting or the destination when receiving, 
>> the rewriter can presumably easily find the additional information 
>> needed to compelete the mapping in its configuration, but for the 
>> destination when transmitting or the source when receiving it must 
>> first discover the mapping.

> Yes.  I believe it'll turn out that this discovery is where the 
> complexity (political if not technical) will lie.  I do not believe it 
> to be a difficult technical problem, however I'm sure any solution 
> proposed will be controversial.

Yes, this is the heart of the matter.

>> Two additional questions:
>> - Is adding options or tunnel headers an option,

> I don't think so.

Ok, I was thinking along the same lines. However, doing the 
negotiation/discovery in options in the first few packets of a stream 
might be a nice way to handle this. I assume this won't be a problem?

>> - Can packets only be rewritten once, or can this happen several 
>> times?

> Address rewriting (at least as described above) would appear to me to 
> be end-to-end transparent.  As such, I'd say yes, although I'm not 
> sure I see the point.

A multihomed site may receive transit from a site that is also 
multihomed. This could happen more often than we expect if single hosts 
also adopt this mechanism, for instance, a laptop "multihomes" to the 
company network and a wireless network.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 2 May 2003 09:29:51 +0200

On onsdag, apr 30, 2003, at 16:19 Europe/Stockholm, Iljitsch van 
Beijnum wrote:

> - Is adding options or tunnel headers an option, or would this make 
> this scheme too unattractive over IPv4-style multihoming?

I would say no. It gives to much complexity on other levels.

>
> - Can packets only be rewritten once, or can this happen several times?
>
>
>
I would say no here was well. Without thinking too much, I would assume 
that this made to much implications on higher protocols.

- kurtis -

---

From: "Tony Li" <[email-masked]>
Date: Sun, 4 May 2003 14:20:29 -0700

|    >>>>> "Tony" == Tony Li <[email-masked]> writes:
|        Tony> Root name servers are also a service deserving of anycast
|        Tony> addresses.
|    
|      But, this is multiple systems with the "same" address rather than
|    a single system with multiple addresses. 
|      So, I don't see the relevance to multi6 :-)

If the point is to bootstrap yourself into some way of finding all of
the DNS servers that contain useful things like name to locator and
name to identifier mappings, then you need to start with a known
locator to begin the process.  As was pointed out, we today start
with a cache of known addresses.  We could simplify this through
unicast and have a smaller set (one?) of known addresses.

Tony