Re: [addr-select-dt] Things to consider for wednesday meeting.

[Tim Chown <[e-mail]>]

On 16 Jun 2010, at 03:15, Arifumi Matsumoto wrote:

> All,
> 
> for tomorrow's meeting, I have these things to share/discuss in mind.
> 
> 1) multihome-without-nat66 activity
> 2) discussions/outputs from IETF77
> 3) remaining issues
> 4) next step

Hi.

First, many thanks for rallying us and organising the call and Tony for the Webex hosting.

Here's my rough notes on what we discussed.  Please do correct/add anything I misunderstood, left out or noted down incorrectly.

1.   multihome-without-nat66 activity

We discussed draft-troan-multihoming-without-nat66-00 and agreed that the draft was relevant to our work and worth reading more closely and contributing to.  There did not seem to be any conflicts.   It may help focus some of our own discussions.

Tim circulated a pointer to 
	draft-huitema-multi6-addr-selection-00
	draft-huitema-multi6-experiment-00
which appear to be older takes on a similar theme.

Tony mentioned his desire to revive his work on ICMPv6 messaging to indicate selection problems/hints.   I haven't reread Christian's drafts yet but I recall a similar idea is mentioned in one of those.

2.  Discussion/outputs from IETF77

I think we agreed it's too early to discuss the specifics of configuration syntax.

3.  Remaining issues

The latest draft from the DT discussion is draft-ietf-6man-addr-select-considerations-00, which just expired and should be refreshed.

How dynamic?  I think we agreed that cases where policy changes might be very dynamic would be where either hosts are moving within a site frequently, or where the site is using very dynamic traffic engineering that may affect external path selections.    For the typical enterprise this would be unusual, as it would be for a typical SOHO network.

We felt that in the general case when a device fetches/receives new address configuration information it should also fetch/receive the policy information.

We didn't discuss policy distribution in non-DHCPv6 networks, though we did say such networks are probably not 'managed' and thus there's less likely to be configured policy to distribute.

On policy conflicts we agreed this was of course a hard problem.   It's also one that's generic to other DHCP-served configuration information not just address selection policy (if we work on that as a solution), and also to conflicts between configuration information received in other ways (perhaps by RFC5006-bis or even manual configuration).   There are also per-interface conflicts, e.g. from a laptop in a 'coffee shop' wireless running a VPN connection to a home site; policy may then apply per prefix in use.   

We did say that the delivery of the configuration information is a 'network' problem while the conflict resolution is a 'host' one, so if that claim is reasonable we could begin to work on these independently (and policy conflict is something 'bigger picture' to include mif WG etc).

The question of legacy hosts was raised.   There was some agreement that this is not an overly important issue.

We seemed to agree that pushing out RFC3484-bis asap was good given many implementors have already applied many of the recommendations that have been made.   See draft-arifumi-6man-rfc3484-revise-02.

4.  Next steps

We talked about the need to get something out (policy distribution method for an enterprise for example) against the likely IETF requirement to consider enough corner cases to make the work valid.   We felt that by abstracting the distribution method to the network and stating the conflict resolution is a per-host issue, we can make progress on at least a DHCPv6-based distribution solution (given our consensus on 'how dynamic' above).

We agreed to try to hold another telecon in 2 weeks or so after discussion on the list.    The list discussion could usefully work on an applicability statement.

We would try to find out the Apple position on address selection implementation for Mac OSX.    It does appear from NANOG that Apple are to implement DHCPv6 'soon'.

Tim