[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updating GSE for the new millennium



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.