Subject: [addr-select-dt] slide to 6man presentation

From: Arifumi Matsumoto <[email-masked]>
Date: Sun, 25 Jul 2010 07:49:21 +0900

Hi,

I drafted the slide for 6man.
This version still has some clear errors, so
I have to fix them.

I really want you all to comment on this.
About the story itself, wording, typos, and whatever.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 26 Jul 2010 15:24:11 +0900

I've got to submit this by Monday evening.
Any comments ?

On 2010/07/25, at 7:49, Arifumi Matsumoto wrote:

> <ietf78-6man-dt.pdf>_______________________________________________
> addr-select-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/addr-select-dt

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Jul 2010 10:13:47 +0100

Hi,

Some comments....

- the DT draft is missed from the slides: draft-ietf-6man-addr-select-considerations-02

May wish to have a slide summarising the most recent focuses in that draft, for example including some/all of:

- frequent policy changes are linked to having either rapid traffic engineering changes/external routing changes or lots of mobile nodes within the site moving between points of attachment with different policies

- it seems sensible to acquire RFC3484 policy when acquiring other configuration information

- in a managed enterprise there is likely to be a managed policy, and DHCP available

- in dynamic/unmanaged networks using routing hints for address selection *may* be more appropriate

- the problem of handling policy conflict is a host issue, the method to distribute the policy is a network issue - we focus here on the network issue since the host issue is broadly applicable to many configuration parameters

- we should avoid delaying progression of a 3484 policy distribution method applicable to managed enterprise networks

I think this material could fit in a new Slide 3 and then you continue the arifumi-6man-addr-select-conflict reference after that, to keep the flow.

I see a new Troan multihoming draft came out this morning, I've not checked what changes there are yet.

Cheers,
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 26 Jul 2010 18:31:05 +0900

Thank you for comments.
I'll update.

BTW, I saw Tony here in Maastricht.
Can you present ??

On 2010/07/26, at 18:13, Tim Chown wrote:

> _______________________________________________

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 26 Jul 2010 20:54:41 +0900

> May wish to have a slide summarising the most recent focuses in that draft, for example including some/all of:

Sorry for that.
I put together these slides from top of my head in the plane. 

However, we should not mention all the changes. To make it simple and easy to focus on the important points.

> - in dynamic/unmanaged networks using routing hints for address selection *may* be more appropriate

I cannot get what exactly mean by this sentence.
Do you assume a environment where a mobile node with multiple interface can make use of routing information for address selection ?

> - the problem of handling policy conflict is a host issue, the method to distribute the policy is a network issue - we focus here on the network issue since the host issue is broadly applicable to…

Important point.
I knew that, but I could not find a space for that.
Maybe we need to add some slides to elaborate.

> - we should avoid delaying progression of a 3484 policy distribution method applicable to managed enterprise networks

Not only enterprise networks, but for networks where multiple upstream networks can talk with each other.

> I see a new Troan multihoming draft came out this morning, I've not checked what changes there are yet.

The main changes are about the legacy host support. Support by using NAT66 to the wrongly source-addressed packets.

Regards,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 26 Jul 2010 20:59:19 +0900

Let me send the ppt and key versions for editing.

Regards,

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 26 Jul 2010 14:35:21 +0200

I can present it, and don't have any further comments other than a TBD
reference for pulling the 'try addr sel again' ICMP from
draft-hain-ipv6-fwrh-03.txt

> -----Original Message-----
> From: [email-masked] [mailto:addr-select-dt-
> [email-masked]] On Behalf Of Arifumi Matsumoto
> Sent: Monday, July 26, 2010 11:31 AM
> To: Tim Chown
> Cc: [email-masked]
> Subject: Re: [addr-select-dt] slide to 6man presentation
> 
> Thank you for comments.
> I'll update.
> 
> > May wish to have a slide summarising the most recent focuses in that
> draft, for example including some/all of:
> >
> > - frequent policy changes are linked to having either rapid traffic
> engineering changes/external routing changes or lots of mobile nodes
> within the site moving between points of attachment with different
> policies
> >
> > - the problem of handling policy conflict is a host issue, the method
> to distribute the policy is a network issue - we focus here on the
> network issue since the host issue is broadly applicable to many
> configuration parameters
> >
> > - we should avoid delaying progression of a 3484 policy distribution
> method applicable to managed enterprise networks
> >
> > I think this material could fit in a new Slide 3 and then you
> continue the arifumi-6man-addr-select-conflict reference after that, to
> keep the flow.
> >

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 26 Jul 2010 21:56:14 +0900

> draft-hain-ipv6-fwrh-03.txt

I don't object to add a reference to that.
But, as the design team, we have not examined what that approach can solve and cannot.

And, personally I have a working group item titled draft-ietf-6man-addr-select-sol that covers possible approaches to the address selection problems. One of which approach is very similar to ICMP error based approach.

Though I cannot argue about what is not yet made public, if it is similar, that approach does not cover all the cases that were raised so far, i.e. destination address selection related cases. And several other issues it has also, like that error-message-driven approach forces a user/host to re-connect to the same host.

So, as a method to update policy in host, IMO, distributing policy-table approach should be the way forward.

---

From: <[email-masked]>
Date: Mon, 26 Jul 2010 16:10:03 +0200

I wonder if you should refer to MIF WG also reviewing WG? Depending on rechartering results, MIF may be working with DHCP based routing distributions etc and might be well interested in this.

The synthesized addresses probably should be prioritized below public IPv4. When comparing synthetic IPv6 to private IPv4, its maybe a matter of taste - assuming ALGs are in place in NAT44 and NAT64 (general preference for IPv6 could win also).  

The prefix used for synthetized IPV6 addresses (if not using well-known-prefix (WKP)) would need to be dynamically detected.. 

Best regards,

Teemu

> [email-masked]] On Behalf Of ext Arifumi Matsumoto
> Sent: 26. heinäkuuta 2010 13:59
> To: Arifumi Matsumoto

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 26 Jul 2010 23:20:30 +0900

Teemu,

thank you for comments.

> I wonder if you should refer to MIF WG also reviewing WG? Depending on rechartering results, MIF may be working with DHCP based routing distributions etc and might be well interested in this.

Yes, I will.

> The synthesized addresses probably should be prioritized below public IPv4. When comparing synthetic IPv6 to private IPv4, its maybe a matter of taste - assuming ALGs are in place in NAT44 and NAT6…

So, you mean
 global IPv4 should be prioritized than synthesized IPv6 address.
 but, private IPv4 may not be prioritized than synthesized IPv6 address.

The RFC3484 revision draft also include a proposal that private IPv4 address should be scoped global. So, if we follow it, we should not differentiate the preferences of global and private.

> The prefix used for synthetized IPV6 addresses (if not using well-known-prefix (WKP)) would need to be dynamically detected.. 

The host itself does not need to detect it, if the NSP distribute an appropriate policy table for it.
Re. WKP, we should have to put it in the default policy table.

---

From: <[email-masked]>
Date: Mon, 26 Jul 2010 16:48:32 +0200

Hi,

> > The synthesized addresses probably should be prioritized below public
> IPv4. When comparing synthetic IPv6 to private IPv4, its maybe a matter
> of taste - assuming ALGs are in place in NAT44 and NAT64 (general
> preference for IPv6 could win also).
> 
> So, you mean

Yes, truly global IPv4 should be higher (hence avoids all NATtting).

> The RFC3484 revision draft also include a proposal that private IPv4
> address should be scoped global. So, if we follow it, we should not
> differentiate the preferences of global and private.

Hence private IPv4 would be considered higher than synthesized IPv6 using WKP? That is fine, probably NAT44 is more reliable than NAT64 (and may have better ALG support).

> > The prefix used for synthetized IPV6 addresses (if not using well-
> known-prefix (WKP)) would need to be dynamically detected..
> 

Ok WKP could be low, and NSP could be distributed with policy table. And isn't it so that if some module on a host learns NSP (e.g. DNS resolver or DHCP or RA), it can modify the policy table accordingly (hence locally generated policy).

Best regards,

Teemu

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 26 Jul 2010 23:59:02 +0900

> Ok WKP could be low, and NSP could be distributed with policy table. And isn't it so that if some module on a host learns NSP (e.g. DNS resolver or DHCP or RA), it can modify the policy table accor…

Of course, I do not preclude such an approach.
But I think, it is better if such a configuration is enforced from the network.
Just like the privacy address preferences should be configurable per network.

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Jul 2010 16:27:36 +0100

> However, we should not mention all the changes. To make it simple and easy to focus on the important points.

That's fine :)

> Do you assume a environment where a mobile node with multiple interface can make use of routing information for address selection ?

Or a node which has multiple addresses from the site being multi-homed, by using for example an ICMP query to an edge router or route server.

> Maybe we need to add some slides to elaborate.

Maybe add after slide 2 and push your policy conflict reference to the slide after that?    I think that would flow well.

> Not only enterprise networks, but for networks where multiple upstream networks can talk with each other.

Yes, sorry, I am biased of course :)

> The main changes are about the legacy host support. Support by using NAT66 to the wrongly source-addressed packets.

OK, thanks.

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Jul 2010 16:29:26 +0100

I think Tony's ICMP hint is worth mentioning in that it should fit into the Troan draft discussion, as it's a possible (part) solution to that problem...

Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Jul 2010 16:35:52 +0100

> And, personally I have a working group item titled draft-ietf-6man-addr-select-sol that covers possible approaches to the address selection problems. One of which approach is very similar to ICMP e…

I think that draft is good in covering general solution spaces, but it does not discuss specifics.   

So Tony has his ICMP draft that is more specific from 3.3 of your draft, and we've implemented an ICMP-based router query message that is a more specific implementation of what's described *very* loosely in 3.2 of your solution space draft.

That said, I think policy distribution is the best way forward, but there may be cases where the other approaches are viable, e.g. if there is no policy distribution (DHCP) server - then the method Tony suggests or the routing hints may offer functionality that's otherwise missing?    But perhaps it's best to discuss these under the Troan draft umbrella and leave the primary DT output to be the policy distribution method?

Tim

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 27 Jul 2010 10:41:30 -0400

Hi Arifumi,
  Sorry for the late comments. The slides look OK.

* What does "NIF metrics" mean in slide 4?

* I am not sure that 6man is the right home for draft-fujisaki-dhc-addr-select-opt . I think it should be taken up as a wg item in dhc with frequent updates to 6man.

Cheers
Suresh 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Arifumi 
> Matsumoto
> Sent: Sunday, July 25, 2010 12:49 AM
> To: [email-masked]
> Subject: [addr-select-dt] slide to 6man presentation
> 
> Hi,
> 
> This version still has some clear errors, so I have to fix them.
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 28 Jul 2010 00:36:12 +0900

Suresh,

thank you for comments.

> * What does "NIF metrics" mean in slide 4?

NIF stands for network interface here.

It makes use of metrics inherent to each network interface.

> * I am not sure that 6man is the right home for draft-fujisaki-dhc-addr-select-opt . I think it should be taken up as a wg item in dhc with frequent updates to 6man.

Recently some proposals of DHCP options are standardized in its home wg with review from dhc.

I thought it should be preferable, because it's not about DHCP itself.

Regards,

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 Jul 2010 11:35:23 +0100

Perhaps just ask Ralph or Jari as Internet Area chairs what they recommend?

Tim

---

From: (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <[email-masked]>
Date: Wed, 28 Jul 2010 23:22:42 +0900 (JST)

Hi DT members,

As 6man chair suggested in yesterday meeting, I revised and submitted
dhcpv6 option draft for 6man wg.

If it's my overeager, please let me know.

# Of course, comments about the draft itself also welcome!

Yours Sincerely,
--
Tomohiro Fujisaki

----------8<----------8=----------8<----------8=----------8<----------
Subject: I-D Action:draft-fujisaki-6man-addr-select-opt-00.txt 
From: [email-masked]
To: [email-masked]
Date: Wed, 28 Jul 2010 06:00:01 -0700 (PDT)
Sender: [email-masked]
Reply-To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Distributing Address Selection Policy using DHCPv6
	Author(s)       : T. Fujisaki, et al.
	Filename        : draft-fujisaki-6man-addr-select-opt-00.txt
	Pages           : 8
	Date            : 2010-07-28

This document describes a new DHCPv6 option for distributing address
selection policy information defined in RFC3484 to a client.  With
this option, site administrators can distribute address selection
policy to control the node's address selection behavior.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fujisaki-6man-addr-select-opt-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 Jul 2010 16:41:17 +0100

It looks like the IETF tools site doesn't realise this is the sequel to draft-fujisaki-dhc-addr-select-opt-09, I'm not sure how to fix this except maybe email the tools maintainer?

Tim

---

From: (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <[email-masked]>
Date: Thu, 29 Jul 2010 21:18:28 +0900 (JST)

Tim,

Thank you for your suggestion. I asked ietf (tools maintainer?).

Yours Sincerely,
--
Tomohiro Fujisaki

From: Tim Chown <[email-masked]>
Subject: Re: [addr-select-dt] slide to 6man presentation
Date: Wed, 28 Jul 2010 16:41:17 +0100

 | It looks like the IETF tools site doesn't realise this is the sequel to draft-fujisaki-dhc-addr-select-opt-09, I'm not sure how to fix this except maybe email the tools maintainer?
 | 
 | Tim
 | 
 | On 28 Jul 2010, at 15:22, (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) wrote:
 | 
 | > 
 | > Hi DT members,
 | > 
 | > As 6man chair suggested in yesterday meeting, I revised and submitted
 | > dhcpv6 option draft for 6man wg.
 | > 
 | > If it's my overeager, please let me know.
 | > 
 | > # Of course, comments about the draft itself also welcome!
 | > 
 | > Yours Sincerely,
 | > --
 | > Tomohiro Fujisaki
 | > 
 | > ----------8<----------8=----------8<----------8=----------8<----------
 | > Subject: I-D Action:draft-fujisaki-6man-addr-select-opt-00.txt 
 | > From: [email-masked]
 | > To: [email-masked]
 | > Date: Wed, 28 Jul 2010 06:00:01 -0700 (PDT)
 | > Sender: [email-masked]
 | > Reply-To: [email-masked]
 | > 
 | > A New Internet-Draft is available from the on-line Internet-Drafts directories.
 | > 
 | > 	Title           : Distributing Address Selection Policy using DHCPv6
 | > 	Author(s)       : T. Fujisaki, et al.
 | > 	Filename        : draft-fujisaki-6man-addr-select-opt-00.txt
 | > 	Pages           : 8
 | > 	Date            : 2010-07-28
 | > 
 | > This document describes a new DHCPv6 option for distributing address
 | > selection policy information defined in RFC3484 to a client.  With
 | > this option, site administrators can distribute address selection
 | > policy to control the node's address selection behavior.
 | > 
 | > A URL for this Internet-Draft is:
 | > http://www.ietf.org/internet-drafts/draft-fujisaki-6man-addr-select-opt-00.txt
 | > 
 | > Internet-Drafts are also available by anonymous FTP at:
 | > ftp://ftp.ietf.org/internet-drafts/
 | > 
 | > Below is the data which will enable a MIME compliant mail reader
 | > implementation to automatically retrieve the ASCII version of the
 | > Internet-Draft.
 | 
 | _______________________________________________
 | addr-select-dt mailing list
 | [email-masked]
 | https://www.ietf.org/mailman/listinfo/addr-select-dt
 | 
 |