Subject: Distributing site-wide RFC 3484 policy

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Jul 2007 20:56:29 +0200

What happened to
http://tools.ietf.org/id/draft-hirotaka-dhc-source-address-selection-opt-01.txt
and is there any other proposal for site-wide distribution of
address selection policy?

As I said at the mike today, I really think we can't avoid
such a mechanism. There *will* be sites running multiple prefixes
(those too small to insist on PI space, but big enough to
need multiple ISPs).

     Brian

---

From: Ralph Droms <[email-masked]>
Date: Mon, 23 Jul 2007 15:10:24 -0400

Brian - draft-hirotaka-dhc-source-address-selection-opt-01.txt was  
first discussed in the dhc WG.  Because there was input that non-DHCP  
solutions to provide site-wide distribution of address selection  
policy, the discussion was moved from the dhc WG to the v6ops WG.   
Detailed consideration of draft-hirotaka-dhc-source-address-selection- 
opt-01.txt has been put on hold pending the outcome of the v6ops WG  
discussion.

- Ralph

---

From: Ruri Hiromi <[email-masked]>
Date: Tue, 24 Jul 2007 04:18:05 +0900

Hi,

The latest version of this draft is today Arifumi mentioned in his  
solution document,
"draft-fujisaki-dhc-addr-select-04.txt" and "draft-v6ops-addr-select- 
ps-01.txt".
We divided previous draft into 2 part, one for distribution protocol  
and the other for problem statement.

At first, we wrote that draft and presented in DHC-wg.  DHC-wg chairs  
suggested us that we need support from other wg such as v6ops. Then  
we are here.

> (those too small to insist on PI space, but big enough to

-------------------------------
Ruri Hiromi
[email-masked]

---

From: Tim Chown <[email-masked]>
Date: Mon, 23 Jul 2007 20:23:13 +0100

I would certainly like to see such a method available.

Tim

-- 
Tim

---

From: [email-masked]
Date: Mon, 23 Jul 2007 17:55:34 -0400

Hi Tim, 
Just though I'd let you know, slides from today's V6OPS on DHCP / Rogue 
RAs seem to be damaged, at least I cannot open them.  Don't know if others 
also have a problem.  Could they be re-posted, please?
Cheers,
Peter Blatherwick

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2007 16:16:37 +0200

Thanks. So does v6ops have an opinion about
draft-fujisaki-dhc-addr-select-04.txt? It seems
nothing will happen unless it's discussed here or
in ipv6.

    Brian

On 2007-07-23 21:18, Ruri Hiromi wrote:
> "draft-fujisaki-dhc-addr-select-04.txt" and 
> "draft-v6ops-addr-select-ps-01.txt".
> We divided previous draft into 2 part, one for distribution protocol and 
> the other for problem statement.
> 
> suggested us that we need support from other wg such as v6ops. Then we 
> are here.
> 
>

---

From: Ruri Hiromi <[email-masked]>
Date: Tue, 24 Jul 2007 23:55:39 +0900

Thanks for the attention.

Before moving to "draft-fujisaki-dhc-addr-select-04.txt", I would  
like to discuss on what is the best way to this WG with solution  
draft.  Because "draft-fujisaki-dhc-addr-select-04.txt" describes  
specific protocol to send policy from dhcp server.

If all of you think we can skip the discussion about solution 
(analysis for the solution) and welcome to move to get into protocol  
work, it is also happy with me.  How do you think?

Or in parallel with solution draft, if we can discuss on the  
distribution of site-wide RFC3484 policy it it better.

Here we already have "problem statement" and "requirement", the  
problems wants to be solved, doesn't it?

On 2007/07/24, at 23:16, Brian E Carpenter wrote:

>> "draft-fujisaki-dhc-addr-select-04.txt" and "draft-v6ops-addr- 
>> select-ps-01.txt".
>> We divided previous draft into 2 part, one for distribution  
>> protocol and the other for problem statement.
>> At first, we wrote that draft and presented in DHC-wg.  DHC-wg  
>> chairs suggested us that we need support from other wg such as  
>> v6ops. Then we are here.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 25 Jul 2007 00:10:21 +0900

>problems wants to be solved, doesn't it?

	it is a bit of "over the top" comment, but my take on this problem is
	(as mentioned at the wg meeting) like below:

	- the entire "source address selection" stuff was a mistake.
	  network has to be deployed so that any ip6_src/ip6_dst pair can go
	  out of the organization somehow.
	  (a) if there's some issue like uRPF in some of your ISPs, the egress
	      routers in your organization should implement source-based
	      routing to workaround it.
	  (b) the whole idea of ULA/ULA-x should be killed at once.
	      we killed site-locals because to this.  do not re-invite
	      rosemary's baby.
	- alain durand said that he would prefer to have single IPv6 address
	  on a node.  i would not go that far (for renumbering and multi-
	  address multihoming) but i object to have addresses with different
	  reachability or "scoping".
	- so, there's no need for you to think about "distributing source
	  address selection policy".

	tnx.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2007 17:42:30 +0200

My belief is that we need a method to distribute 3484 policy
in any case, even if we adopt another approach to the general problem.

     Brian

On 2007-07-24 16:55, Ruri Hiromi wrote:
> Before moving to "draft-fujisaki-dhc-addr-select-04.txt", I would like 
> to discuss on what is the best way to this WG with solution draft.  
> Because "draft-fujisaki-dhc-addr-select-04.txt" describes specific 
> protocol to send policy from dhcp server.
> 
> If all of you think we can skip the discussion about solution(analysis 
> for the solution) and welcome to move to get into protocol work, it is 
> also happy with me.  How do you think?
> 
> Here we already have "problem statement" and "requirement", the problems 
> wants to be solved, doesn't it?
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2007 18:01:44 +0200

itojun,

> 	  reachability or "scoping".

Yes, they are horrible, but they are not possible to avoid in the complex
topology created by corporate networks and VPNs.

    Brian

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 25 Jul 2007 01:05:10 +0900

>topology created by corporate networks and VPNs.

	do you plan to have source addresses with different reachabilty with
	VPN and stuff, even with IPv6 where no private address would be
	deployed hopefully?

	of course you can run IPsec tunnels or other VPN technologies by using
	global IPv6 addresses.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2007 18:18:00 +0200

> 	VPN and stuff, even with IPv6 where no private address would be

I wouldn't design things that way, but I believe that corporate notions
of security and business partnerships will cause this to happen.
In fact I agree with Phill Hallam-Baker that the *best* way to solve
this is by applications-level strong security such as Web Services Security,
but I am not optimistic that this will be adopted by everybody.
> 	of course you can run IPsec tunnels or other VPN technologies by using

Yes, but you may still have complexity because only some hosts in company A
can reach only some hosts in B via the VPN. DNS gets complex and messy too.

    Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 01:40:17 +0900 (JST)

> but I am not optimistic that this will be adopted by everybody.

	if you agree with Phill, you should make efforts to that direction!

> can reach only some hosts in B via the VPN. DNS gets complex and messy too.

	yeah, there are various ways to solve DNS issues, i don't think there
	is a perfect solution.  but DNS issue does not have to do things with
	IP-layer reachability.

itojun

---

From: Ruri Hiromi <[email-masked]>
Date: Wed, 25 Jul 2007 01:48:25 +0900

I understood your opinion in one sense, but there might have been  
problematic cases with reality.

some part are same as Brian, and we has been tried to write in the  
Problem statement

- Currently we already have coexistence of VPN access and Global  
Internet Access in a site
- demands for controlling prefixes exists in some cases
- ULA has been reached consensus among IETF
- demands for controlling v4-v6 preference

If you have further comments of the cases we listed up in it seems to  
be found wrong, let me know.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 01:58:48 +0900 (JST)

> Internet Access in a site

	as i respnoded to Brian this is a non-issue.

> - demands for controlling prefixes exists in some cases

	this has to be done sorely with routing table using ip6_dst, nothing
	else.  if you use ip6_src for controlling routing, you will go into
	paradise of "policy routing" that is, basicaly, a pitfall towards hell.

> - ULA has been reached consensus among IETF

	this does not mean that we have to use ULA.  moreover, RFC4291 do
	state that addresses other than ::, ::1, ff00::/8, fe80::/10 are
	global unicast, so ULA violates it in some sense.  with "global
	unicast" basically i assume "global reachability".

	sorry that i show up a bit late, but i have been taking medical leave.

	i should write up a draft or two to deprecate ULA.

> - demands for controlling v4-v6 preference

	maybe, but what would you need more than "IPv6 then IPv4"?

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2007 20:39:10 +0200

>       with "global

I think we discovered during the original ULA discussion
that global scope and global uniqueness do not imply
global reachability. We have no way to express VPN style
reachability using scopes.

    Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 07:18:42 +0900 (JST)

> >       with "global unicast" basically i assume "global reachability".
> 

	as i mentioned previously, VPN is about how to
	- encrypt/authenticate communication with your laptop and your
	  organization (like IBM)
	- and pretend that you are inside your organization network

	there's no real point in using, or requiring, ULA for this.
	you can just use IBM PI or PA for the IPv4/v6 address inside the
	IPsec tunnel.  i wonder what Apple corporate VPN is using - i guess
	it would be within 17.0.0.0/8.

itojun

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Jul 2007 07:43:28 +0900

> 	it would be within 17.0.0.0/8.

Please think about a case like you wanna use the Internet at home and at 
the same time the enterprise network via VPN connection.
The address you get from the latter network is IPv6 global address but 
its scope is limited to the enterprise network.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 07:53:51 +0900 (JST)

> its scope is limited to the enterprise network.

	so do you mean that your enterprise does not have external connectivity?
	how do you use Google from your enterprise, for instance?

itojun

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Jul 2007 08:01:33 +0900

> 	as i respnoded to Brian this is a non-issue.

I replied about this point in another email.

> 	paradise of "policy routing" that is, basicaly, a pitfall towards hell.

I think you've already mentioned the benefit of policy routing, haven't 
you ? As far as the source address is used for some reasons, such as
routing and access control, I believe there should be demand for control
the source address to be chosen.

> 	maybe, but what would you need more than "IPv6 then IPv4"?

At least, I know there is a motivation for smooth transition
to IPv6, such as,
IPv4 only
  -> IPv4 and IPv6 with lower preference
   -> IPv4 and IPv6 with higher preference
    -> IPv6 only.

Another case may be a network administrator knows that the
quality of IPv6 connectivity is clearly worse than that of
IPv4 because of tunneling or something.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 08:12:12 +0900 (JST)

> the source address to be chosen.

	just as a last resort, when things like uRPF gets in your way.

	i guess i do not need to talk about what "policy routing" is, but
	here goes.

	without policy routing, the routing table would be a mapping between
	2^128 ip6_dst to 2^128 gateways or neighbors.

	with policy routing, the mapping would be from (2^128 ip6_dst) x
	(2^128 ip6_src) to 2^128 gateways or neighbors.  normally people
	describe it by having 2 mapping tables, and you can get conflicting
	results due to those 2 tables.  it is a never-ending maze.

>    -> IPv4 and IPv6 with higher preference

	you are assuming that you are watching everything over from the sky,
	high above, like god.  that is not how we made largely-distributed
	system, the Internet, work.

> IPv4 because of tunneling or something.

	you just have to switch to better IPv6 provider.

itojun

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Jul 2007 08:18:29 +0900

> 	so do you mean that your enterprise does not have external connectivity?

External connectivity isn't necessarily available for VPN users,
because VPN connection is usually for retrieving resources in
enterprise network like e-mail and web pages.
Even if it's available, you may not love to use degraded-quality
connectivity instead of not degraded one.

> 	how do you use Google from your enterprise, for instance?

We are told to use home-made search engine, instead of Google ;)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jul 2007 01:20:02 +0200

> 	how do you use Google from your enterprise, for instance?

Today, I fear it is often NATted. Obviously that is not the future.

I expect to see many enterprises use ULA for internal traffic
and PA or PI for Google. But I was actually thinking about VPNs between
business partners, which create "fingers" of reachability for small
subsets of address space that are shared by pairs of enterprises.
This can get very complex when many companies have mutual business
relationships. I can't even think how to draw it in ASCII art.

     Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 08:30:13 +0900 (JST)

> connectivity instead of not degraded one.

	but the above problem is not specific to VPN, right?
	- you have some connectivity from your laptop - either directly from
	  your laptop or via some router(s)
	- some connectivity is restricted compared to another, in some way
	  such as (a) bandwidth (b) price (c) NATed (d) slow (e) inefficient
	  path due to tunnelling (f) limited reachability (g) you name it.

	it really is a policy routing problem.  you have to solve it WITHOUT
	global knowledge.  the way you (and probably other guys) are proposing
	with "distribution of policy table" is, using god's point-of-view.

	and after more than 10 years of policy routing researches, there's not
	a single viable solution, as far as i know.

> We are told to use home-made search engine, instead of Google ;)

	so that you cannot find offensive stuff or they can keep track of
	keywords.  ok, i hope you are happy with that environment :-)

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 08:38:52 +0900 (JST)

> Today, I fear it is often NATted. Obviously that is not the future.

	and fortunately and/or unfortunately, recent protocols do not have
	problem with the presense of NAT, such as Skype :-P

> relationships. I can't even think how to draw it in ASCII art.

	i wonder if the complexity and adminstration costs pays off...

itojun

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Jul 2007 08:56:05 +0900

> 	system, the Internet, work.

I guess you misunderstood what I mean ?
I'm not looking down from the sky.

I'm looking at a small part at the edge of the Internet.
A small company want to move to ipv6 and want to minimize
troubles and risks. Then they want to transition to IPv6
in the way I described above.

> 	you just have to switch to better IPv6 provider.

So, give me money please ;)

I guess not so many company can have good-quality ipv6
connectibity from the start.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Jul 2007 09:07:16 +0900 (JST)

> in the way I described above.

	of course you are watching over from the sky.  you are sure that
	for the enterprise source address X is better to reach destination A,
	and Y is beter for B.  that is a knowledge (or kludge) about the
	entire internet, which can only be obtained from the god's point of
	view.

	to give you an idea: the situation changes over time by BGP peering
	status and alike, and you have no real way to catch up other than
	to update your policy table master config file.  scary and high admin
	cost unless you do not get paid from your organization.

> So, give me money please ;)

	so you are spending more money on bad management technology and
	management labor costs, rather than to spend money for decent IPv6
	connectivity services with less expensive management costs.
	hmm.

> connectibity from the start.

	we are both from Japan, and we have NTT and IIJ at least!
	wait a minute, your domain name seems to be nttv6.net...

itojun

---

From: james woodyatt <[email-masked]>
Date: Tue, 24 Jul 2007 19:12:11 -0500

On Jul 24, 2007, at 17:18, Jun-ichiro itojun Hagino wrote:
>
> i wonder what Apple corporate VPN is using - i guess it would be  
> within 17.0.0.0/8.

When Internet Connect.app establishes L2TP/IPsec VPN connections, it  
inserts a bunch of host routes to all the private remote subnets, any  
or all of which may have RFC 1918 addressed subnets or globally  
addressed subnets, e.g. Apple uses all of 17/8, plus several other  
allocations, some of which are RFC 1918 subnets.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Jul 2007 12:43:27 +0900

> 	cost unless you do not get paid from your organization.

What I'm talking here is not about reachability or quality of 
connection. It's just about smooth transition from what we
have today to what we will have tomorrow. One day transition
may not be realistic, though. And it's about the unpredictable
troubles including system failures and also reachability problem
because of local mis-configuration or something like that rather
than the Internet status.

> 	wait a minute, your domain name seems to be nttv6.net...

We and many of people in this ML have good v6 connectivity, I hope.
 From now, we have to make every other people move onto v6 world, right ?

---

From: Tim Chown <[email-masked]>
Date: Wed, 25 Jul 2007 15:41:50 +0100

> 	problem with the presense of NAT, such as Skype :-P

Well, if everyone was behind NAT, and there were no public IP supernodes,
Skype would presumably have more problems?

Also, Skype would surely have been easier to develop originally without
having to consider NAT traversal in the system architecture.

> 	i wonder if the complexity and adminstration costs pays off...

BTW if you want to make ASCII art (RFC diagrams :) easier to draw, I 
found Email Effects very good.

-- 
Tim

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 25 Jul 2007 13:13:38 -0500

Le 07-07-23 à 13:56, Brian E Carpenter a écrit :
> such a mechanism.

I agree with Brian. There must be a way for enterprises to push a  
RFC3484 policy to its nodes.

I went into this discussion with a large enterprise customer who  
wanted to carefully control how v6 will be deployed in an incremental  
way. some of the enterprise sites would be v6 ready, others will be  
v6 enabled but not so ready, etc... therefore, pushing different  
RFC3484 policies depending on the sites is very useful in this  
context. Policy #1 could be the default policy(prefer v6), policy #2  
would be prefer ipv4.  It is also pretty useful when nodes are mobile  
and move from sites to sites and then get the site network rfc3484  
policy while attaching to the network.

It will also help applications developers since we are seeing  
applications developers forcing v4 to prefer v6, disabling v6, etc...  
if rfc3484 policy can be pushed to nodes, then these changes to  
applications would be less useful, since the enterprise network  
manager would be able to tell the nodes, (and then the applications)  
what are the best version of IP to use on the attached network.

Marc.

> There *will* be sites running multiple prefixes

-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Jul 2007 17:25:36 -0500

On 24-jul-2007, at 10:10, Jun-ichiro itojun Hagino wrote:

>> Before moving to "draft-fujisaki-dhc-addr-select-04.txt",

Can't find a draft with that name...

> 	  out of the organization somehow.

That ship has sailed. Even if you could, through some kind of  
herculian effort, make it so that only a single IPv6 address is  
available per host rather than 1 or more for 1 or more interfaces,  
there's going to be the issue of having both an IPv4 and an IPv6  
address. I currently have a mail client that won't fall back to IPv4  
if IPv6 doesn't work. That's not acceptable.

> 	      routing to workaround it.

When a host has selected addresses, other boxes can't overrule that.  
The best thing you can do is generate a quick unreachable so the host  
can retry with a different source/dest address combination.

> 	  (b) the whole idea of ULA/ULA-x should be killed at once.

No it shouldn't. People want it, no reasonable counter arguments have  
been presented.

> 	  reachability or "scoping".

You should have spoken up somewhere in the last century. This stuff  
is a done deal today, no point in turning back halfway and turning  
back completely is not possible at this point.

> 	  address selection policy".

Deciding for other people what they don't need is extremely impolite.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Jul 2007 17:34:07 -0500

> RFC3484 policy to its nodes.

It occurs to me that we're trying to solve a subset of the full  
problem here. There is lots of site-wide stuff that may potentially  
be distributed. Stuffing those in DHCP and/or RAs is problematic  
because we essentially need to redo this every time a new piece of  
information is found that needs to be distributed, and because it  
would get too big. I don't think a nice, complex RFC 3848 table will  
necessarily fit into less than a kilobyte, which is the most you can  
possibly borrow from DHCP/RA.

Once you have connectivity, downloading data of arbitrary size,  
providing information of an arbitrary nature, is trivial through well- 
known mechanisms such as HTTP. The only missing piece is the name/ 
address of a small set of servers that are initially queried for this  
information. And this is something that will fit in a DHCP or RA  
message.

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 25 Jul 2007 17:40:34 -0500

Le 07-07-25 à 17:34, Iljitsch van Beijnum a écrit :

> would get too big. I don't think a nice, complex RFC 3848 table  
> will necessarily fit into less than a kilobyte, which is the most  
> you can possibly borrow from DHCP/RA.
>
> Once you have connectivity,

well, but the policy will enable you to have that connectivity. If  
the policy the node currently have is wrong, then the node might not  
reach the server you are talking about.

> downloading data of arbitrary size, providing information of an  
> arbitrary nature, is trivial through well-known mechanisms such as  
> HTTP. The only missing piece is the name/address of a small set of  
> servers that are initially queried for this information. And this  
> is something that will fit in a DHCP or RA message.

ok, so you agree on the idea, but you prefer another method than DHCP  
or RA. Maybe you should write a draft on the method you are proposing?

Marc.

-----

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 26 Jul 2007 07:46:06 +0900

>if IPv6 doesn't work. That's not acceptable.

	you are talking about a separate story.  the thread is about having
	to run source-address selection between IPv6 addresses with different
	"scope" or reachability.

	and if you keep the default source address election policy table,
	it is a non-problem for me.  i see problems in the entire idea of
	"distributing policy table".

>can retry with a different source/dest address combination.

	normal application which makes outgoing TCP connection DOES NOT
	perform bind(2), so the application will only try all of the
	destination addresses available on the DNS, not all the src/dst pairs.

	so it would be better for us to provide connectivity to all of the
	cases in the network setup, instead of making the end node complicated
	with all of the source address selection goo.

>No it shouldn't. People want it, no reasonable counter arguments have  

	think about it.  then why "site-local" was killed after a long long
	debate?

>back completely is not possible at this point.

	ok, i have been using the internet since 1989 or something.  so maybe
	i'm from the stone age.

	i have NEVER deployed RFC1918 network in my home!  i paid extra JPY
	to get a small IPv4 address block instead of single IPv4 adderss,
	and i now run IPv6-only wireless segment in my home, just like we did
	for some of the past IPv6-enabled IETF meetings.

	and when i work on IPv6, i always envision to provide a better
	networking environment to everyone on the planet (6 bilion or more
	people).  i see the long-term happiness with lower admin cost than
	short-term happiness with NAT, ULA or whatever, since there are only
	a little number of people who can administer network, and we need
	to deliver the technology to those people as well.  maybe it has
	something to do with cultural background :-)

>Deciding for other people what they don't need is extremely impolite.

	is it impolite to stop people from going into a pitfall?  or do i
	keep silence and see people go into the pitfall and injured?

	we've been through all this discussion at KAME, in 1998-2000 timeframe.
	it was our failure that we did not document the discussion, but we
	normally document stuffs that we got as a "successful" outcome of the
	discussion.  they are available as RFCs or i-ds.

itojun

---

From: Ruri Hiromi <[email-masked]>
Date: Thu, 26 Jul 2007 07:47:05 +0900

Oops, let me correct the draft name and URI, it is;
http://www.ietf.org/internet-drafts/draft-fujisaki-dhc-addr-select- 
opt-04.txt

Regards,

On 2007/07/26, at 7:25, Iljitsch van Beijnum wrote:

> address. I currently have a mail client that won't fall back to  
> IPv4 if IPv6 doesn't work. That's not acceptable.
>
> When a host has selected addresses, other boxes can't overrule  
> that. The best thing you can do is generate a quick unreachable so  
> the host can retry with a different source/dest address combination.
>
> No it shouldn't. People want it, no reasonable counter arguments  
> have been presented.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Jul 2007 01:02:10 +0200

> Can't find a draft with that name...

draft-fujisaki-dhc-addr-select-opt-04 actually

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 26 Jul 2007 12:26:49 +0900

Iljitsch van Beijnum wrote:
> It occurs to me that we're trying to solve a subset of the full problem 
> here. There is lots of site-wide stuff that may potentially be 
> distributed. Stuffing those in DHCP and/or RAs is problematic because we 
> essentially need to redo this every time a new piece of information is 
> found that needs to be distributed, and because it would get too big. I 
> don't think a nice, complex RFC 3848 table will necessarily fit into 
> less than a kilobyte, which is the most you can possibly borrow from 
> DHCP/RA.
> 
> providing information of an arbitrary nature, is trivial through 
> well-known mechanisms such as HTTP. The only missing piece is the 
> name/address of a small set of servers that are initially queried for 
> this information. And this is something that will fit in a DHCP or RA 
> message.

It's just a matter of how to use the mechanism.
For example, RFC4191 delivers routing info to hosts, which limits
its usage for local routing information in that it discourages
the dynamic interaction with the routing systems.

I suppose the same should be true for this source address
selection mechanism too. We have a lot of problems in our hands,
but that doesn't necesarily mean we have to solve them at once
and that is not always the best way.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Jul 2007 22:32:20 -0500

> the policy the node currently have is wrong, then the node might  
> not reach the server you are talking about.

Quite right. That would be the "finding the light switch in the dark"  
problem.  :-)

However, I don't think RFC 3484 policy information is so essential  
that finding a (presumably) local server to get that information from  
in the absence of said information would be impossible even after  
several retries.

So this mechanism would apply to all information that is not  
essential to base connectivity.

> ok, so you agree on the idea, but you prefer another method than  
> DHCP or RA. Maybe you should write a draft on the method you are  
> proposing?

I guess I should. But not this week...

> IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca

Mine is Running IPv6, Apress, 2005, http://www.runningipv6.net/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 Jul 2007 22:46:48 -0500

> 	to run source-address selection between IPv6 addresses with different

I'm very much interested in achieving the following:

Get both ADSL and cable connectivity from competing providers (or  
fill in two last 1609 meter technologies of your choice), where each  
of those connections has a separate gateway attached that doesn't  
know about the other gateway. Both announce a PA block from the ISP  
in question using stateless autoconf. My hosts configure with two  
addresses and two default gateways, and use the appropriate gateway  
with a given source address. When an application can't connect using  
one source/dest pair, it tries the others until there is a working  
connection.

Other people are interested in the following situation:

Set of servers A has a public facing side, heavily firewalled, and a  
private side. Set of servers B doesn't talk to the outside world, but  
does talk to servers A on the private side so optimum safety is  
accomplished without having firewalls etc on the private side for  
cost/performance reasons.

I don't see how using public address space for the private  
interconnection between the two sets of servers makes sense.

> 	destination addresses available on the DNS, not all the src/dst  

In shim6 I have spoken up to avoid pushing this functionality into  
applications, but although the application is not the good place for  
it, if it's not done elsewhere, it will have to be done in applications.

And smart implementers will create a layer that takes care of these  
details. Annoying, yes. Necessary, absolutely.

> 	cases in the network setup,

And how exactly do you do that in a world where mobile devices roam  
from network to network, often with overlap between two forms of  
connectivity and connectivity going away without prior warning?

> 	think about it.  then why "site-local" was killed after a long long

Ambiguity.

> 	is it impolite to stop people from going into a pitfall?

Some pitfalls, and certainly this one, are in the eye of the beholder.

>         or do i

If you know a better way, by all means...

---

From: Gert Doering <[email-masked]>
Date: Thu, 26 Jul 2007 16:03:58 +0200

Hi,

> what are the best version of IP to use on the attached network.

I wholeheartly agree with that.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 26 Jul 2007 23:33:31 +0900 (JST)

> one source/dest pair, it tries the others until there is a working  

	i would like to name the devices/networks like:

		ISP-A	ISP-B
		  |	  |
		RT-A	RT-B
		  |	  |
		==+=======+== PREFIX-A:0::/64, PREFIX-B:0::/64
		  | ADDR-A/128, ADDR-B/128
		your machine

	now, first of all, you really cannot define/determine what is the
	best combination among the following to reach the destination, X.
	X could be within ISP-A, ISP-B, or totally far end of the planet with
	rather long AS path.  the evaluation would make about "the best"
	combination would make you a god looking from above.  what you can
	do is to pick one and hope.
		use ADDR-A out of PREFIX-A:0::/64 and use RT-A
		use ADDR-A out of PREFIX-A:0::/64 and use RT-B
		use ADDR-B out of PREFIX-B:0::/64 and use RT-A
		use ADDR-B out of PREFIX-B:0::/64 and use RT-B

	next, depending on operating system on your machine, the treatment of
	default router differs.  this is outside of the "source address
	selection".
	- some implementation picks the default route out of RT-A/B at will
	- some implementation do install both RT-A/B as the default gateway
	  but it uses only one of them
	- some implementation tries to perform load-balancing

	moreover, if you set up another link to set up firewall or something,
	you really do not have any idea to pick among RT-A or RT-B.  i have
	been suggesting you to leave it to be handled by routing table among
	routers, and/or configuration between RT-A/RT-B.  it would be seriously 
	painful to make "your machine" know about all the details about your
	network egress points, it does not scale and you will have
	configuration mistakes.

		ISP-A	ISP-B
		  |	  |
		RT-A	RT-B
		  |	  |
		==+=======+== PREFIX-A:0::/64, PREFIX-B:0::/64
		  |
		router
		  |
		==+======= PREFIX-A:1::/64, PREFIX-B:1::/64
		  | ADDR-A/128, ADDR-B/128
		your machine

	if one of/both of ISP practices filtering such as uRPF, you would
	have to narrow down the choices so that you would pick PREFIX-A for
	RT-A (ISP-A), and PREFIX-B for RT-B (ISP-B).  but it is routing
	protocol to decide, normally.  you may want to configure RT-A and RT-B
	to meet this requirement, read RFC3178 for more details.

> interconnection between the two sets of servers makes sense.

	if you have firewall device to begin with, there is no difference
	at all even if you pick a global address for B, or address with
	limited scope (site-local, ULA, whatever).  in fact, if you pick a
	global address it would be easier for A to handle traffic from B.

> details. Annoying, yes. Necessary, absolutely.

	no please don't.  for god's sake.  we would need another 10 years to
	adapt software, include sendmail, ruby, python, postfix, procmail,
	you name it, to the new API.

> connectivity and connectivity going away without prior warning?

	i do not get what you mean.  more concrete example please?

> > 	think about it.  then why "site-local" was killed after a long long

	RFC3879 seems to have more reasons other than "Ambiguity".

> If you know a better way, by all means...

	so i have been trying to...

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 26 Jul 2007 23:40:28 +0900 (JST)

oh btw, there was a related posting on [email-masked], you may want to
	check it out.

itojun

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 27 Jul 2007 02:45:49 +0900

> 	with "distribution of policy table" is, using god's point-of-view.

When you have two connectivity that have different reachability, address 
selection and routing have to be appropriately controlled to avoid 
connection failure.

When you have two connectivity that have different characterisitic, such 
as bandwidth, price, delay and you name it, isn't it clear that people 
want to use their two connectivity as they wanted to. Of course they 
don't have global knowledge, at least they have knowledge of their own 
network.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 27 Jul 2007 02:58:29 +0900 (JST)

> don't have global knowledge, at least they have knowledge of their own 

	so you know that "local optimization != overall success".
	then why are you spending so much time trying to make incomplete
	local optimization?

itojun

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 27 Jul 2007 02:59:35 +0900

Brian E Carpenter wrote:
>>> Please think about a case like you wanna use the Internet at home and 
>>> at the same time the enterprise network via VPN connection.
>>> The address you get from the latter network is IPv6 global address 
>>> but its scope is limited to the enterprise network.
>>

In IPv4, you can access to multiple different scoped networks owing
to NAT. When you want to access the global Internet, your address
will be overitten by global IPv4 address somewhere, and when you
want to access rather private system, your address will not be changed
or changed to another private address.

How do you make this network move onto the v6 world ?
I believe one of the possible and practical answer is to have multiple
addresses attached to a host combined with appropriate address selection
control.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 Jul 2007 14:26:50 -0500

> 	rather long AS path.

That's why it's useful to have a mechanism that can tell you "try to  
reach X over B" in the case that X is much easier/faster/cheaper to  
reach over B than over A.

> 	- some implementation tries to perform load-balancing

Right. As I've said before, I'd like my system to make sure that when  
I use source address A/128 I go out over ISP A and when I use source  
address B/128 I go out over B. Then you said you tried that and you  
didn't like it so you reverted back to ignoring the address/route  
relationship. Then I asked why but so far, no answer.

> 		==+======= PREFIX-A:1::/64, PREFIX-B:1::/64

Right, in this situation my machine wouldn't be able to select the  
exit path. (Note that Marcelo Bagnulo and Christian Huitema had a  
draft about this in multi6 for some time.) That doesn't mean it's not  
useful to have the capability when the host CAN make the decision. As  
an operator, I can always remove the router in the middle. I can't  
realistically rewrite my IP stack.

> 	protocol to decide, normally.

So?

> 	limited scope (site-local, ULA, whatever).

Of course there is. If I have public space, I receive packets. I need  
an ISP. When I change ISPs, I have to renumber. All reasonable things  
if I actually want to go out and connect to the world, but NOT for a  
private interconnect.

>   in fact, if you pick a

Nonsense.

> 	you name it, to the new API.

Fortunately, stuff that doesn't do this too well works most of the  
time. But yes, it's necessary to make software smarter. The idea that  
you get a single address and that it works 100% of the time is plain  
broken.

> 	i do not get what you mean.  more concrete example please?

I can connect to the internet over the cell phone network or through  
wifi. Both are wireless so they drop out from time to time when you  
move around. Each has their own address, so my address keeps changing  
all the time and when both are active I have two addresses.

A dumb TCP/IP stack that sends packets with a wifi source address  
over the cell network is a problem here. So is a dumb application  
that will try to connect over wifi when I'm out of range of the base  
station and doesn't retry over the cell network.

> 	so i have been trying to...

You warn against doing something, you are not providing a better  
alternative.  :-)

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 27 Jul 2007 05:02:08 +0900 (JST)

> reach over B than over A.

	see below.

> relationship. Then I asked why but so far, no answer.

	what i've said is, it MAY NOT best to use ADDR-A to go out from
	ISP-A!  you cannot see the EGP routing table of ISP-A (unless you are
	insider) so you have no (or very little) idea!

	as long as you use RT-A consistenly, there's no issue with multipath
	TCP packet reordering.

> realistically rewrite my IP stack.

	so you cannot rewrite your IP stack but you are saying you can rewrite
	all of your application to use something next to getaddrinfo(3).
	i see some contradiction.

> > 	global address it would be easier for A to handle traffic from B.

	well, if you say "so?" or "nonsense", that is total denial from making
	a constructive argument.  it isn't an argument clinic ala monty python.

	or maybe not a constructive argument - i should say goodbye and try
	to deploy IPv6 to other people, and then you will be left with IPv4.

> you get a single address and that it works 100% of the time is plain  

	i do not think we can.  Geoff's prediction is around 2010, remember?
	you may disagree, but i do not think IPv4 will last until 2020 honestly.
	wanna bet some USD?

> station and doesn't retry over the cell network.

	- session-layer protocol
	- mip6 (eeks)
	- some other secret plans i got :-)

> You warn against doing something, you are not providing a better  

	you need a hearing aid or new pair of glasses, i guess.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 26 Jul 2007 15:59:02 -0500

On 26-jul-2007, at 15:02, Jun-ichiro itojun Hagino wrote:

> 	ISP-A!

Well, then make a policy entry that tells the host what is the best  
combination.

(Ignoring the obvious ingress filtering problem for a moment.)

>         you cannot see the EGP routing table of ISP-A (unless you are

What's your point?

> 	as long as you use RT-A consistenly, there's no issue with multipath

There is no rule against reordering IP or TCP packets.

> 	i see some contradiction.

No, you're being difficult, and I'm starting to think it's on purpose.

The vendors have to make the software do what's right. I can  
rearrange the hardware in my network if that makes everything work  
better.

> 	a constructive argument.  it isn't an argument clinic ala monty  

Saying that a global address is better than a private address for a  
function that doesn't need the functionality of a global address  
WITHOUT EXPLAINING WHY THAT WOULD BE SO is even worse. Are we still  
having a useful discussion?

I'm getting pretty tired of these based-on-nothing arguments against  
ULAs. Come up with a reason why they're so bad or shut up about them.  
That goes for all ULA haters, btw.

> 	to deploy IPv6 to other people, and then you will be left with IPv4.

Oh right.

http://lists.apple.com/archives/Ipv6-dev/2007/May/msg00011.html

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 27 Jul 2007 06:17:09 +0900

>Well, then make a policy entry that tells the host what is the best  

	but again, you have no idea what is *the best* combination.

>(Ignoring the obvious ingress filtering problem for a moment.)

	i have responded to issues with uRPF in a separate paragraph in one of
	the previous emails.

>> 	insider) so you have no (or very little) idea!

	you (as a customer of ISP-A and ISP-B) cannot guess what is the
	best combination of src/dst address pair to go out from RT-A/B,
	or how to choose one of the ISPs/routers to go out.

>There is no rule against reordering IP or TCP packets.

	there is none, but there's performance implication.
	see RFC2991 section 2.

>No, you're being difficult, and I'm starting to think it's on purpose.

	no, i'm just trying to understand what you are saying.

>rearrange the hardware in my network if that makes everything work  

	so what is the reason behind (1) you can rewrite all of your
	applications and (2) you cannot rewrite your IP stack?  you'd better
	describe.

>That goes for all ULA haters, btw.

	you are, again, missing my point.  i have been against of the idea of
	- having addresses with different reachability, including site-local
	  and ULA (which is zombie of site-local)
	- having to control selection of those addresses in the end node,
	  i.e. source address selection policy table
	- and to make it worse, the need of deploying policy table into the
	  organization nodes
	got an idea?

itojun
PS: i'm in chicago until tomorrow morning so catch me whenever you are
available.  email is a terrible media to communicate.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 27 Jul 2007 09:10:41 +0900

> available.  email is a terrible media to communicate.

Of course, it is.
But would you please tell me the summary of the conversation,
so that everybody can follow it.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 27 Jul 2007 09:09:25 +0900

> 	then why are you spending so much time trying to make incomplete

They may want local optimization for their success.
Though it may be incomplete, if it brings them a kind
of success for their purpose, why other people can
stop it ?

---

From: David Malone <[email-masked]>
Date: Fri, 27 Jul 2007 11:04:32 +0100

> 	then why are you spending so much time trying to make incomplete

One could ask similar questions of BGP. Despite that, people find
BGP a useful tool, and while not perfect, it seems to remain bearable
for many network operators.

Personally, I'd find a mechanism for distributing address selection
policy useful. I have a number of sites that have both 6to4 and
native/tunnelled connectivity where the latter has uRPF applied.
I'd like our hosts to use all native addressing, unless they are
talking to a 6to4 host. Unfortunately, not all hosts have the right
default policy. If I could distribute a policy, they I could arrange
for everyone to have the right policy.

It's true that I probably can't get produce a policy to do the right
thing all the time, but that makes address selection no worse than
the routing protocols in use today. I guess your point may be that
we shouldn't have address selection at all, but I fear it may be
too late for that discussion?

	David.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jul 2007 14:50:34 +0200

itojun,

> i have been against of the idea of

I think we understand that you don't like this, but we did reach rough
consensus in the ipv6 WG to define ULAs with complete understanding that
global scope is not global reachability.

Just to repeat the argument, reachability is set by router configurations
so you cannot assume that *any* prefix has global reachability,
whether it is PA, PI, or ULA.

    Brian

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 27 Jul 2007 21:53:41 +0900

>whether it is PA, PI, or ULA.

	true, i know that.  because of
	- BGP peering policies between ISPs
	- nationwide censorship/whatever
	- organization filtering/whatever
	you cannot really assume you have a full reachability towards the
	entire planet even if you are using global address (2000::/3).

	but the degree of reachability (or unreachability) is entirely
	different between site-local/ULA and global address.  there's no
	comparison.

itojun

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 27 Jul 2007 15:22:22 +0200 (CEST)

> too late for that discussion?

I fully support argument of David. I think RFC3484 is important piece to 
define IPv6 preference or IPv4 preference. At least I currently use this 
purpose... Setting up address selection has to be made somehow manageable: 
this is an important requirements from a network manager point of view. It 
is nightmare to manage mass of machines with arbitrary address selection 
policy....

Best Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jul 2007 17:12:57 +0200

> 	different between site-local/ULA and global address.  there's no

Fully agreed. But we don't know how to capture that in scope rules.
I think that is the basic problem.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 27 Jul 2007 10:41:55 -0500

> 	but again, you have no idea what is *the best* combination.

Not in all cases, but someimes, I do.

> 	- and to make it worse, the need of deploying policy table into the

Hm, could it be that the problem you foresee is where www.example.com  
has both global::/128 and ula::/128 where people from outside are  
supposed to connect to the global address and people from the inside  
to the ula address?

Although I can see one or two cases where people may want this, I  
would agree that such a setup is a bad idea. However, if you have  
www.example.com with global::/128 and secret-internal- 
only.example.com with ula::/128 that would make sense and not cause  
problems.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jul 2007 18:39:23 +0200

Pref
> supposed to connect to the global address and people from the inside to 
> the ula address?
> 
> Although I can see one or two cases where people may want this, I would 
> agree that such a setup is a bad idea.

Normally the security people would dislike this - the globally available
boxes will be in the DMZ, not in the intranet. If you decide to trust
end-system security and run without a DMZ, I suppose this could happen,
and we certainly need to assume it will happen.

> However, if you have 
> www.example.com with global::/128 and secret-internal-only.example.com 
> with ula::/128 that would make sense and not cause problems.

Indeed, I think this will be common practice for servers. But for
clients (employee desktops) both ula and global addresses are needed,
or you will rapidly need a ULA-to-Global NAT. (P2P would be the same.)

(ASCII art, view in Courier)

              ULA to ULA  -----------
  --------  <..........> | internal  |
|employee|              | server    |
|desktop |               -----------                ----------
  --------  <..........................{ DMZ }....> | external |
               Global to Global                     | server   |
                                                     ----------

     Brian

---

From: Gert Doering <[email-masked]>
Date: Fri, 27 Jul 2007 19:07:54 +0200

Hi,

> 	or how to choose one of the ISPs/routers to go out.

There is big disagreement here.   You might not able to find the "global
optimum", but there are valid scenarios where the user can know that
specific combinations of source and destination addresses are *good*,
and other combinations are not so useful.

Like:

  - for connections to my corporate VPN use source address A
  - for all the rest, use source address B

argueing that this is "not useful, because you can't know the global
situation" is denying that local constraints can exist that need local
rules.

Gert Doering
        -- NetMaster

---

From: YOSHIFUJI Hideaki / 吉藤英明 <[email-masked]>
Date: Fri, 27 Jul 2007 14:28:27 -0500 (CDT)

Hello.

First of all, I would agree the PS itself.
And, I would agree the distributing address selection "hints",
but I am not in favor having the "policy" itself get distributed.

The end-node clients may have their own "policy" and/or implementation
details (e.g., an implementation may have special tunnel or
special (and useful) policy for the implementation), and they must be
taken into account.

And, only the "end-node" can know the full view of reachability.
Routers or other entity may suggest end-node to use another source address(es)
(or prefix(es)), but it can not be ultimate (or god's) order.
In that sense, we might need to solve this issue in conjunction with
rrg work.

Anyway, the draft contains a horrible error, at least.
We CAN NEVER specify zone-index from outside the box.  It MUST be removed.
And, I would say, we must make it clear that the information is
"relative" or "virtual" and the end-node retain having final decision.

Regards,

-- 
YOSHIFUJI Hideaki @ USAGI Project  <[email-masked]>
GPG-FP  : 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jul 2007 21:39:57 +0200

> special (and useful) policy for the implementation), and they must be

This is a standard issue in any policy distribution mechanism -
if there are two sources for policy (e.g. local and central),
which one wins? That needs to be defined in the mechanism.
Sometimes, the site-wide policy will win, because the IT Management
has authority.

> (or prefix(es)), but it can not be ultimate (or god's) order.

Correct. Reachability will always win.

> In that sense, we might need to solve this issue in conjunction with

Well, LISP reachability is interesting, but still not as certain
as a successful SYN/ACK.

     Brian

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Sat, 28 Jul 2007 05:03:16 +0900 (JST)

| Anyway, the draft contains a horrible error, at least.
 | We CAN NEVER specify zone-index from outside the box.  It MUST be removed.

I'm not sure why the error(?) is 'horrible', but we discussed about
'zone-index' in DHC wg ML.

http://www1.ietf.org/mail-archive/web/dhcwg/current/msg04683.html

If the site administrator knows the detail of a client, it may be
possible to specify that value for the client.

Anyway, currently, we try to define the option proposed in
draft-fujisaki-dhc-addr-select-opt-04 so as to deliver the RFC3484
policy table as it is.

--
Tomohiro Fujisaki

---

From: YOSHIFUJI Hideaki / 吉藤英明 <[email-masked]>
Date: Fri, 27 Jul 2007 15:55:53 -0500 (CDT)

Hello.

> possible to specify that value for the client.

You CANNOT specify "zone" itself from out of the box.

If an implementation supports a kind of "zone" in policy,
the node may want to restrict the rule only on that "interface"
(or zone) which the dhcpv6 message has arrived, but no other way.

Server may ask the node to restrict the policy within the interface,
but it cannot ask the end-node to use another specific interface.

Or, are you suggesting to have mapping between fake "zone-index" and the
real one?

Anyway, I'd say, you CANNOT distrubute the polocy itself, but you could
suggest a "hint" to end-nodes, with "virtual precedence" (or "relative
precedence"), "virtual label" and "virtual zone-index" (or "zone label").

Regards,

--yoshfuji

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Sat, 28 Jul 2007 07:30:43 +0900 (JST)

| >  | Anyway, the draft contains a horrible error, at least.
 | >  | We CAN NEVER specify zone-index from outside the box.  It MUST be removed.
 | > 
 | > I'm not sure why the error(?) is 'horrible', but we discussed about
 | > 'zone-index' in DHC wg ML.
 | > 
 | > http://www1.ietf.org/mail-archive/web/dhcwg/current/msg04683.html
 | > 
 | > If the site administrator knows the detail of a client, it may be
 | > possible to specify that value for the client.
 | 
 | You CANNOT specify "zone" itself from out of the box.
 |
 | If an implementation supports a kind of "zone" in policy,
 | the node may want to restrict the rule only on that "interface"
 | (or zone) which the dhcpv6 message has arrived, but no other way.
 | 
 | Server may ask the node to restrict the policy within the interface,
 | but it cannot ask the end-node to use another specific interface.
 | 
 | Or, are you suggesting to have mapping between fake "zone-index" and the
 | real one?
 | 
 | 
 | Anyway, I'd say, you CANNOT distrubute the polocy itself, but you could
 | suggest a "hint" to end-nodes, with "virtual precedence" (or "relative
 | precedence"), "virtual label" and "virtual zone-index" (or "zone label").

Do you mean node local information should not be given from outside ?

We think if a node is in an administrative scope and zone index value
is static (not dynamically changes when node restarts), it is possible
to deliver that value to the node.

And if there is a case that utilizes zone index delivery, we should
remain zone index delivery as it is, and limit the usage in
specification. If there is no case, delivering we should not deliver
zone index.

--
Tomohiro Fujisaki

---

From: Perry Lorier <[email-masked]>
Date: Sat, 28 Jul 2007 13:35:18 +1200

> Sometimes, the site-wide policy will win, because the IT Management
Non-local policy belongs to an Interface.  The "Home network interface" 
policy discusses what you can do via that interface, the "Corporate VPN" 
policy describes what you can use the Corporate VPN for.

Local policy is how you merge these policies.  eg say I have three 
interfaces on my laptop at the moment:

* Wireless to my home network.
The policy for this says "prefer me preferentially for the local network 
stuffs" "I provide a native v6 internet connection (ie, globally scoped 
addresses can be sent this way", etc

* VPN to my corporate workplace
The policy for this says "You can connect to local corporate services 
preferentially" "Provide non-preferential access to some services such 
as an Internet connection"

* IP over the cellular network (GPRS, CDMA, EVDO whatever)
This policy for this says "I can provide an internet connection"

Local policy says "treat wireless + vpn as equal, then below that prefer 
cellular connection".  Thus the policies all get merged together to end 
up with:

If it's for the local home network use the wireless      High Priority
If it's for the company addresses, use the VPN            High Priority

If it's for a normal (globally scoped) address, use the wireless      
Medium Priority

If it's for a globally scoped address, use the VPN         Low Priority
If it's for a globally scoped address, use the expensive, slow 
cellphone   Low Priority

Thus a networks responsibility is to present what features it has and 
how that network wants to be used (what source addresses it recommends 
for what, what connections it's willing to provide). Local policy is how 
to choose between different networks on it's various interfaces.  Local 
policy could in theory override one given to it by the network, but of 
course if it tries to do something the network doesn't provide 
reachability towards it won't work.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 31 Jul 2007 17:10:21 +0900

At Sat, 28 Jul 2007 07:30:43 +0900 (JST),

> to deliver that value to the node.

(I guess you know this but just to clarify the point...)  The problem
is that scope zone indices are (at least currently) node-local
information that an external entity such as a DHCP server or the site
administrator doesn't (cannot) know.  A combination of magical or
infeasible techniques (e.g. automatic zone-ID discovery or allocation,
or manual configuration of the mappings of IF-zone IDs for all
possible clients) might make it possible, but I don't think it's a
feasible option at all today, and I doubt it will become realistic in
the near future.

So,

> specification. If there is no case, delivering we should not deliver

I'd suggest removing the zone-index field for now.  We could keep it
for future extensibility (which I guess you're proposing), but I
suspect the field will need heavy, possible backward incompatible,
revision anyway when we ever address the above difficulties.  So I
don't think having it with uncertainty will actually help in the
future.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]