headers
David Conrad | 1 May 02:45
Favicon

Re: updating GSE for the new millennium

Iljitsch,

On Wednesday, April 30, 2003, at 07:19  AM, Iljitsch van Beijnum 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).

> 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.

> The first order of business is the address rewriting. It seems to me 
> that the different options here (GSE-like one-way rewriting upper bits 
> with globally unique lower bits, MHAP double rewriting) can be 
> accommodated by doing the following:
>
> When transmitting, for both the source and destination address: take a 
> globally unique N bit label and map to one of several possible IPv6 
> address suitable for routing associated with this label. When 
> receiving, map the addresses back to labels.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Peter Tattam | 1 May 04:27
Picon

Re: updating GSE for the new millennium

On Wed, 30 Apr 2003, David Conrad wrote:

> Iljitsch,
> 
> On Wednesday, April 30, 2003, at 07:19  AM, Iljitsch van Beijnum 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).
> 
> > 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.
> 
> > The first order of business is the address rewriting. It seems to me 
> > that the different options here (GSE-like one-way rewriting upper bits 
> > with globally unique lower bits, MHAP double rewriting) can be 
> > accommodated by doing the following:
> >
> > When transmitting, for both the source and destination address: take a 
> > globally unique N bit label and map to one of several possible IPv6
(Continue reading)

Permalink | Reply | 10 comments |
headers
David Conrad | 1 May 05:45
Favicon

Re: old GSE idea

Going back through some old unanswered (sorry 'bout that) email...

On Thursday, April 17, 2003, at 04:59  AM, Iljitsch van Beijnum wrote:
>>>> I think the simplest solution is to make the lower 64 bits globally 
>>>> unique.
>>> This breaks autoconfiguration.
> MAC address collisions are not uncommon.
...
> The problem is that on a LAN, you can do DAD, but doing that world 
> wide each time you connect to the network is no fun.

Understood.  Seems to me this is one of the tradeoffs.  Globally unique 
identifiers in the lower 64 bits allows for a very simple mapping 
mechanism to map that identifier into one or more locators giving you 
both site and host multi- and re-homing.  If you cannot guarantee 
global uniqueness of those identifiers, then to get the same 
functionality, you increase the complexity of the mapping mechanism.

>> Why put location back into identity?  In my view, endpoint 
>> identifiers are 'names'.  They are a flat, undifferentiated (from the 
>> network perspective, administratively, you may want some hierarchy) 
>> identifier space.
> This is going to be a problem if you want to look these up in a 
> distributed database. We really need a hierarchy for something like 
> this.

I do not disagree that you want hierarchy.  What I am saying is that 
you do not want is to tie that hierarchy into network topology such 
that if the object changes its location in the network topology, you 
must change the identifier.  You want an administrative hierarchy
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Conrad | 1 May 06:22
Favicon

Re: old GSE idea

Mostly just thinking out loud here (if this is still permitted)...

On Thursday, April 17, 2003, at 10:58  AM, Christian Huitema wrote:
> Even if we solved MAC address collision on a single link, you have to
> remember that a host can be multi-homed to several interfaces. Whatever
> we do to support the survival of TCP connections should also work when
> the traffic moves from interface A to interface B, e.g. from 802.11 to
> GPRS. In such cases, the two interfaces are likely to belong to
> different sites, and are like to use different interface identifiers
> (since they indeed are different interfaces). The solution of "just
> using 64 bits" will not work there.
>
> -- Christian Huitema
>

If you define the multi-homed 'site' to be the host then I think it 
will.

and

On Thursday, April 17, 2003, at 12:35  PM, Christian Huitema wrote:
> Sure. Another issue is privacy. I don't necessarily want different ISP
> to be able to correlate that two traffic flows do in fact originate 
> from
> the same hosts. In fact, privacy advocates would go ballistic if we
> mandated that.

No reason (other than efficiency) that a globally unique ID must be 
permanently assigned to an interface.  If you can verify global 
uniqueness in a reasonably rapid fashion, you just auto-generate a new
(Continue reading)

Permalink | Reply | 627 comments |
headers
David Conrad | 1 May 07:53
Favicon

Re: updating GSE for the new millennium

On Wednesday, April 30, 2003, at 07:27  PM, Peter Tattam wrote:
>> Depending on your approach, it may not be necessary to rewrite the
>> source address.
>
> I don't think it's necessary.  The less changes to the packet, the 
> better in my
> opinion.  Just map the N bit label at whatever point a decision has to 
> be made
> to forward the packet outside the site.  I think only one relabelling 
> should be
> allowed and the decision to relabel be based on on the pre-labelled 
> address.

Agreed.

> I would presume that a MH address be identifiable by just looking at 
> the address
> (i.e. the top M (where M < N) bits represent a particular class of MH
> addresses).

Why would you not want all addresses to be multi-homable?  Why add the 
complexity of figuring out whether an address is multi-homable or not?

> Once the labelling is done, it can be sent all the way to the end
> host.  If one retains the prelabelled source address, this is an 
> additional tag
> to the end point that the packet can have it's label removed.

Right.  To put one approach I've been toying with in more concrete 
terms:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Peter Tattam | 1 May 08:42
Picon

Re: updating GSE for the new millennium

On Wed, 30 Apr 2003, David Conrad wrote:

> On Wednesday, April 30, 2003, at 07:27  PM, Peter Tattam wrote:
> >> Depending on your approach, it may not be necessary to rewrite the
> >> source address.
> >
> > I don't think it's necessary.  The less changes to the packet, the 
> > better in my
> > opinion.  Just map the N bit label at whatever point a decision has to 
> > be made
> > to forward the packet outside the site.  I think only one relabelling 
> > should be
> > allowed and the decision to relabel be based on on the pre-labelled 
> > address.
> 
> Agreed.

Additionally, I think it is a bad idea to relabel the source as the label
supplied is unlikely to be the best path.  The other end needs to determine
this. 

> 
> > I would presume that a MH address be identifiable by just looking at 
> > the address
> > (i.e. the top M (where M < N) bits represent a particular class of MH
> > addresses).
> 
> Why would you not want all addresses to be multi-homable?  Why add the 
> complexity of figuring out whether an address is multi-homable or not?
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Conrad | 1 May 09:34
Favicon

Re: updating GSE for the new millennium

Peter,

On Wednesday, April 30, 2003, at 11:42  PM, Peter Tattam wrote:
> Additionally, I think it is a bad idea to relabel the source as the 
> label
> supplied is unlikely to be the best path.  The other end needs to 
> determine
> this.

Agreed.

>> Perhaps I misunderstand.  If the original values are restored before
>> delivery at the final destination, the TCP/UDP checksums would compute
>> correctly and IPSec would not be affected.
>
> For a TCP connection, the srce/dest part of checksum can be cached.  
> One just
> has to agree on knowing when to include the srce/dest pair in the 
> checksum.
> Another reason for determining if the packet is clean or dirty.  Minor
> optimization that's all.  Don't forget that in Ipv6 we don't do IP 
> header
> checksumming any more.

Right.  Not convinced this would be necessary, but understand what 
you're saying.

> We need to search for protocols that depend on the addresses in the 
> header
> being intact and work out whether the packet needs to be reconstructed
(Continue reading)

Permalink | Reply | 6 comments |
headers
Peter Tattam | 1 May 12:36
Picon

Re: updating GSE for the new millennium

On Thu, 1 May 2003, David Conrad wrote:

> Peter,
> 
> On Wednesday, April 30, 2003, at 11:42  PM, Peter Tattam wrote:
> > Additionally, I think it is a bad idea to relabel the source as the 
> > label
> > supplied is unlikely to be the best path.  The other end needs to 
> > determine
> > this.
> 
> Agreed.
> 
> >> Perhaps I misunderstand.  If the original values are restored before
> >> delivery at the final destination, the TCP/UDP checksums would compute
> >> correctly and IPSec would not be affected.
> >
> > For a TCP connection, the srce/dest part of checksum can be cached.  
> > One just
> > has to agree on knowing when to include the srce/dest pair in the 
> > checksum.
> > Another reason for determining if the packet is clean or dirty.  Minor
> > optimization that's all.  Don't forget that in Ipv6 we don't do IP 
> > header
> > checksumming any more.
> 
> Right.  Not convinced this would be necessary, but understand what 
> you're saying.
> 
> > We need to search for protocols that depend on the addresses in the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 1 May 12:47
Favicon

Re: updating GSE for the new millennium

On donderdag, mei 1, 2003, at 04:27 Europe/Amsterdam, Peter Tattam 
wrote:

> I think only one relabelling should be allowed

Apart from the question if this is what we want, is this something we 
can enforce? Or should care to enforce? This would give ISPs the option 
of relabeling just so their customers can't do it themselves.

> I would presume that a MH address be identifiable by just looking at 
> the address (i.e. the top M (where M < N) bits represent a particular 
> class of MH addresses).

Doing this has the advantage we can always easily recognize an 
unrewritten multihomed address, but is that a big enough advantage to 
require this? I can imagine a situation where hosts use a regular 
prefix as long as this prefix works and only rewrite with a secondary 
prefix when the first one fails.

> The main issues I can see behind restoring the original packet would 
> be TCP/UDP
> checksums and IPSec.  If the two end points are labelling aware, 
> measures can
> be taken to ignore the label from the checksums or replace it for 
> IPsec,
> otherwise it would be up to labelling boxen (border routers or other) 
> to do
> this on behalf of the hosts which are unaware of the labelling 
> possibility.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 May 10:32
Favicon

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane