Subject: [shim6] Exit selection [New Version Notification - draft-mrw-nat66-08.txt]

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Mar 2011 08:55:56 +1300

Diverted from the v6ops list:

On 2011-03-09 06:22, Rémi Després wrote:
> Le 3 mars 2011 à 20:48, Brian E Carpenter a écrit :
>> ...
>> Of course. PI has the cost of exploding the BGP4 table.
>> NPTv6 has the cost of destroying address transparency.
>>
>> Since SHIM6 has neither of these costs, are you surprised
>> that I prefer it?
> 
> SHIM6 is a solution, but AFAIK it needs that hosts know:
> - their global addresses
> - means to force outgoing paths that go via the right CPE's (an ingress-filtering constraint) 

This is well understood to be an issue for shim6.

How about rechartering the WG to resolve this?

The tail end of the charter says:

 Dec 2010  	Submit implementation report to IESG for publication as Informational RFC
 Dec 2010 	Submit applicability document to IESG for publication as Informational RFC
 Dec 2010 	Close or re-charter

Where is the implementation report, BTW? And when will the applicability
draft be ready for the IESG?

      Brian

> In a site using ULAs and having several links, a complement is therefore needed. 
> SAM is an approach for this (ref. draft-despres-softwire-sam-01 - sec. 3.3), and AFAIK the only documented one so far.
> Would you agree on this?
> 
> RD
> 
> 
> 
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 08 Mar 2011 22:36:53 +0100

> draft be ready for the IESG?

from the editors side, this is already the case.

> _______________________________________________
> shim6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shim6

---

From: Sébastien Barré <[email-masked]>
Date: Tue, 08 Mar 2011 22:56:15 +0100

Hi,

Op 08-03-11 20:55, Brian E Carpenter schreef:
>
> Where is the implementation report, BTW?
I have proposed an implementation report a while ago, but received no 
comment about it (as far as I remember).
It is now an expired draft, but I can revive it if there is motivation 
from people to review it. It can still be downloaded from here: 
http://inl.info.ucl.ac.be/publications/shim6-implementation-report-linshim6

If anyone is interested in reviewing/commenting on it, I will be happy 
to apply the comments and do my best to improve it. We can also discuss 
in Prague as I will be there.

regards,

Sébastien.
> And when will the applicability

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Mar 2011 13:05:53 +1300

It's for the WG chairs to say, but I think we should pursue this
WG deliverable, *and* recharter to work on the exit selection
issue.

I remain optimistic about shim6. Its time may come in a few years
when the dust has settled from the IPv6 deployment panic. So we
should finish the job.

Regards
   Brian Carpenter

On 2011-03-09 10:56, Sébastien Barré wrote:
>>> SAM is an approach for this (ref. draft-despres-softwire-sam-01 -
>>> sec. 3.3), and AFAIK the only documented one so far.
>>> Would you agree on this?
>>>
>>> RD
>>>
>>>
>>>
>>>
>>>

---

From: Rémi Després <[email-masked]>
Date: Wed, 9 Mar 2011 09:19:31 +0100

Le 9 mars 2011 à 01:05, Brian E Carpenter a écrit :

> when the dust has settled from the IPv6 deployment panic.

> So we

+1
IMHO, practical use of shim6 will become really interesting when the exit-selection problem is also completely solved.

RD

---

From: Scott W Brim <[email-masked]>
Date: Fri, 11 Mar 2011 14:13:15 -0500

Shim6 itself cannot select an exit.  In all but trivial cases the network
has the intelligence and must be involved (e.g. the exit points).  Given
that one has to involve the network, then an exit selection mechanism is not
just for Shim6 but for anything that can take advantage of multiple src+dst
pairs, and it should not be Shim6-specific.  Therefore whatever needs doing,
I recommend that it not be done in Shim6 but somewhere more general --
IntArea WG looks like a good place.

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Mar 2011 08:22:14 +1300

Scott,

That may well be true, but shouldn't we work here to define the
requirements from the shim6 point of view?

I must go and read the MIF documents sometime. It could be they
have already defined sufficient requirements for shim6.

   Brian

---

From: Scott W Brim <[email-masked]>
Date: Fri, 11 Mar 2011 15:07:58 -0500

> requirements from the shim6 point of view?

OK, sounds good.

> have already defined sufficient requirements for shim6.

When you do, and you feel frustrated, please contribute :-)

---

From: Rémi Després <[email-masked]>
Date: Sat, 12 Mar 2011 17:32:54 +0100

Le 11 mars 2011 à 20:13, Scott W Brim a écrit :

> Shim6 itself cannot select an exit.  In all but trivial cases the network has the intelligence and must be involved (e.g. the exit points).  Given that one has to involve the network, then an exit selection mechanism is not just for Shim6 but for anything that can take advantage of multiple src+dst pairs, and it should not be Shim6-specific.  

> Therefore whatever needs doing, I recommend that it not be done in Shim6 but somewhere more general -- IntArea WG looks like a good place.

+1

RD

---

From: Geoff Huston <[email-masked]>
Date: Mon, 14 Mar 2011 08:14:14 +1100

>> Therefore whatever needs doing, I recommend that it not be done in Shim6 but somewhere more general -- IntArea WG looks like a good place.

wg co-chair hat OFF

I appreciate that in the context of the IETF saying "we should not do this" is invariably like standing in front of a bulldozer, and like the bulldozer, it rarely has any effect - but nevertheless I want to share with you a personal opinion that we should not do this! :-)
 
I have two problems with this issue of "exit selection". 

Firstly, I recall the demise of the site-local scoped address in IPv6. The compelling argument for me was one of inability of self-awareness of context. i.e. it was never clear where the edge of a site actually lay. So let me replay the same problem statement here - what is an "exit" and how does a packet know when it has gone through it? And how does a router "know" its the exit router and not an interior router? In the context of nested sites (e.g. workgroup, department, faculty) whats _the_ exit?

Secondly, its not just the problem of scope of a site here. Its also trying to clearly understand the nature of the problem and place that into juxtaposition with the various proposed "solutions." From memory the various exit selection solutions proposed in the context of shim6 were all various forms of source-address based forwarding, and for me its getting the cart well and truly before the horse. Hop-by-hop stateless destination-based forwarding is an incredibly powerful architectural concept in packet networks, and any other forwarding mechanism tends to invoke copious quantities of complexity and state, and should only be contemplated as a last resort of the desperate rather than the first line solution. So why was exit selection an issue in shim6? Surely if routing is working, and shim6 does not assume broken routing, if a route to a destination is offered, then its a valid route. So why select exits that are not being offered by routing as being on the best path? From my memory I believe it was because some folk  thought that a) unicast reverse route filtering would be prevalent in IPv6 and that b) clients could not negotiate filters with their provider.  But is a) true? and is b) really true? Frankly I'm pretty sceptical that this is the case and it concerns me that this is a case of over solving.

my 2c anyway

   Geoff

---

From: Sander Steffann <[email-masked]>
Date: Sun, 13 Mar 2011 22:23:44 +0100

Hi Geoff,

> From my memory I believe it was because some folk  thought that a) unicast reverse route filtering would be prevalent in IPv6 and that b) clients could not negotiate filters with their provider.  But is a) true? and is b) really true? Frankly I'm pretty sceptical that this is the case and it concerns me that this is a case of over solving.

From my personal experience here in The Netherlands: a) yes, b) yes. At least for home users and small/medium sized businesses. A lot of them use cheap DSL based internet access, and they do uRPF for IPv4 and refuse to deploy an IPv6 service that can not do uRPF. And because the service is cheap, the ISP has no budget for b)...

- Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2011 11:32:25 +1300

On 2011-03-14 10:14, Geoff Huston wrote:
>>> Shim6 itself cannot select an exit.  In all but trivial
>>> cases the network has the intelligence and must be
>>> involved (e.g. the exit points).  Given that one has to
>>> involve the network, then an exit selection mechanism is
>>> not just for Shim6 but for anything that can take
>>> advantage of multiple src+dst pairs, and it should not be
>>> Shim6-specific. Therefore whatever needs doing, I
>>> recommend that it not be done in Shim6 but somewhere more
>>> general -- IntArea WG looks like a good place.
>> +1
>> 
> 
> wg co-chair hat OFF
> 
> I appreciate that in the context of the IETF saying "we
> should not do this" is invariably like standing in front of a
> bulldozer, and like the bulldozer, it rarely has any effect -
> but nevertheless I want to share with you a personal opinion
> that we should not do this! :-)

If by "we" you mean the shim6 WG, I'm inclined to agree,
beyond documenting that this problem needs to be solved
generically for IPv6. I don't believe shim6 is really a
special case: once you have prefixes from and exits to several
different ISPs, you have a potential problem.

> Firstly, I recall the demise of the site-local scoped address
> in IPv6. The compelling argument for me was one of inability
> of self-awareness of context. i.e. it was never clear where
> the edge of a site actually lay. So let me replay the same
> problem statement here - what is an "exit" and how does a
> packet know when it has gone through it? And how does a
> router "know" its the exit router and not an interior router?
> In the context of nested sites (e.g. workgroup, department,
> faculty) whats _the_ exit?

The host and the departmental router cannot know the answer to
that question, I fear, without erecting some very complicated
machinery.

> 
> Secondly, its not just the problem of scope of a site here.
> Its also trying to clearly understand the nature of the
> problem and place that into juxtaposition with the various
> proposed "solutions." From memory the various exit selection
> solutions proposed in the context of shim6 were all various
> forms of source-address based forwarding, and for me its
> getting the cart well and truly before the horse. Hop-by-hop
> stateless destination-based forwarding is an incredibly
> powerful architectural concept in packet networks, and any
> other forwarding mechanism tends to invoke copious quantities
> of complexity and state, and should only be contemplated as a
> last resort of the desperate rather than the first line
> solution. 

I fully agree. That would be baroque, and despite having started
this conversation, I am not in favour of a host-based or even
departmental-router-based solution.

> So why was exit selection an issue in shim6? Surely
> if routing is working, and shim6 does not assume broken
> routing, if a route to a destination is offered, then its a
> valid route. So why select exits that are not being offered
> by routing as being on the best path? From my memory I
> believe it was because some folk  thought that a) unicast
> reverse route filtering would be prevalent in IPv6 and that
> b) clients could not negotiate filters with their provider.
> But is a) true? and is b) really true? 

Well, it seems from other responses that both are real problems,
but not specific to shim6. draft-v6ops-multihoming-without-nat66
talks about this, and at first sight, a valid approach for
the problems described in that draft would work just fine for
shim6 too. Maybe shim6 people should read that draft carefully.

    Brian

> Frankly I'm pretty
> sceptical that this is the case and it concerns me that this
> is a case of over solving.
> 
> my 2c anyway
> 
> Geoff
> 
> 
> _______________________________________________ shim6 mailing
> list [email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Mon, 14 Mar 2011 09:58:17 +1100

> From my personal experience here in The Netherlands: a) yes, b) yes. At least for home users and small/medium sized businesses. A lot of them use cheap DSL based internet access, and they do uRPF f…

wg co-chair hat still off

It may be (is?) heretical in the context of this wg, but at the low end of the market that is highly cost and process constrained, as the subject line refers, NAT66 is an obvious approach that does not try and jump through the trapeze hoops of trying to do hop-by-hop forwarding based on source address in a general manner..

:-)

  Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2011 12:16:39 +1300

> It may be (is?) heretical in the context of this wg, but at the low end of the market that is highly cost and process constrained, as the subject line refers, NAT66 is an obvious approach that does…

If you mean NPTv6, yes, it's heresy but it will no doubt get its
share of the market. I see shim6 and multihoming-without-nat as
part of the longer term future for medium scale enterprise sites.

   Brian

---

From: Geoff Huston <[email-masked]>
Date: Mon, 14 Mar 2011 10:22:03 +1100

On 14/03/2011, at 9:32 AM, Brian E Carpenter wrote:

> generically for IPv6.

As might be evident from my positing I'm of the view that this is
a case of "nothing to see here, move along" and therefore I personally 
disagree that this "problem" needs to be solved. (but I also appreciate
that in the IETF this never works and the IETF is often more
obsessed with the rathole than the larger landscape.  :-)

> I don't believe shim6 is really a

> that question, I fear, without erecting some very complicated

That's my understanding of the situation!

> shim6 too. Maybe shim6 people should read that draft carefully.

indeed,

  Geoff

---

From: Fred Baker <[email-masked]>
Date: Sun, 13 Mar 2011 18:09:26 -0700

On Mar 13, 2011, at 4:16 PM, Brian E Carpenter wrote:

> If you mean NPTv6, yes, it's heresy but it will no doubt get its share of the market. I see shim6 and multihoming-without-nat as part of the longer term future for medium scale enterprise sites.

Very possibly, if you can get enterprise networks to deploy it. At this point, it is largely DOA. What do you think the reason might be?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Mar 2011 16:24:41 +1300

> Very possibly, if you can get enterprise networks to deploy it. At this point, it is largely DOA. What do you think the reason might be?

IMHO:

Firstly, because it isn't in Windows.

Secondly, because it was explicitly badmouthed by various operators a couple
of years ago, in my opinion because they didn't really understand it and
were just getting to grips with the immediate problems of deploying v6
at all.

Thirdly, because we really don't need it yet. We don't need it for
early adopters of v6 and we don't need it for very large enterprises
who can perfectly well use PI/BGP4. We also don't need it for
SOHO users, who manage well enough behind NAT44 and will manage well
enough behind NPTv6.

We'll find out in a few years whether we need shim6 for the medium
size enterprises who will discover that they want address transparency.

Oh, and we'd better make IPv6 renumbering work too. BOF in Prague.

   Brian

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 Mar 2011 10:32:51 +0100

> Firstly, I recall the demise of the site-local scoped address in IPv6. The compelling argument for me was one of inability of self-awareness of context. i.e. it was never clear where the edge of a site actually lay. So let me replay the same problem statement here - what is an "exit" and how does a packet know when it has gone through it?

The problem that needs a solution (be it called "exit selection" or otherwise) is that of a domain where:
- several global PA prefixes are assigned to several independent border nodes
- routing is done across several links in an address family other than global IPv6 (e.g. with ULA's to avoid renumbering in case of a change in the set of PA prefixes)
- some hosts need e2e address transparency (e.g. for SHIM6)

> And how does a router "know" its the exit router and not an interior router? In the context of nested sites (e.g. workgroup, department, faculty) whats _the_ exit?

Let "border node" replace "exit router" as name of a node that is assigned a PA on upstream network and that also deals with the local address family.  
Now:
- e2e transparency can be preserved by encapsulating of e2e packets in locally routable packets.
- in addition to its local address, a SHIM6 host must know its (multiple) global addresses 
- if it also knows, for each PA appearing at the head of its global addresses, the local address of the border node to be used when transmitting with this PA in its source addresses, it can address encapsulating packets to the right border node using this address.

This is the approach I tried to introduce with SAM for multihoming (draft-despres-softwire-sam-01 sec 3.3), but, as SAM was presented as a generic tool, it was found to have too large a scope. 
Its applications have then progressed under different names:
- 4rd for stateless IPv4 across IPv6
- 6a44 for native IPv6 across NAT44-CPE's

Its application to global IPv6 across ULA's didn't receive a name yet because it didn't catch much attention so far. 
Let me propose "Geetalad" for Generic E2E Transparency Across Local Addressing Domains.

What about a bar bof in Prague?

> Secondly, its not just the problem of scope of a site here. Its also trying to clearly understand the nature of the problem and place that into juxtaposition with the various proposed "solutions." From memory the various exit selection solutions proposed in the context of shim6 were all various forms of source-address based forwarding, and for me its getting the cart well and truly before the horse.

> Hop-by-hop stateless destination-based forwarding is an incredibly powerful architectural concept in packet networks, and any other forwarding mechanism tends to invoke copious quantities of complexity and state, and should only be contemplated as a last resort of the desperate rather than the first line solution.

Full agreement that routing within the domain has to remain as is, hop-by-hop stateless (this is the case with SAM/Geetalad). 

> So why was exit selection an issue in shim6? Surely if routing is working, and shim6 does not assume broken routing, if a route to a destination is offered, then its a valid route. So why select exits that are not being offered by routing as being on the best path?

> From my memory I believe it was because some folk  thought that a) unicast reverse route filtering would be prevalent in IPv6 and that b) clients could not negotiate filters with their provider.  

> But is a) true?

I am not sure about what is actually done by various providers, but the fact is that ingress filtering is necessary to avoid source address spoofing.
It is therefore an elementary security tool.

> and is b) really true?

Even if possible, negotiating filters would be an operational burden, both for providers and for customers.
If the border node that has been assigned a PA is always traversed by packets leaving the domain with this PA in source addresses, there is no need for it.

> Frankly I'm pretty sceptical that this is the case and it concerns me that this is a case of over solving.

A solution that combines multihoming, local addressing independence, and shim6, is IMHO worth having, especially if it is stateless and straightforward.

> my 2c anyway

Thanks for your 2c.
I hope you will be interested in mine.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 Mar 2011 10:42:28 +0100

> that question, I fear, without erecting some very complicated

Complicated, not that I know if its involving hosts is accepted (see below)

> departmental-router-based solution.

Well, if host based is the only complete solution, it shouldn't IMHO be taboo. 

> shim6 too. Maybe shim6 people should read that draft carefully.

I agree that it is a valid approach.
However, AFAIK, it doesn't deal with ULA's:
- it assumes that hosts have their global IPv6 addresses
- it doesn't say how global addresses would traverse domains in which ULA's are used.
In this respect, the SAM approach is complementary.

RD