Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt

From: Chris Grundemann <[email-masked]>
Date: Thu, 12 Jan 2012 13:24:49 -0700

On Fri, Dec 16, 2011 at 03:49, Tim Chown <[email-masked]> wrote:
> Well, there are two questions here.
>
> One is whether the WG believes the update as described in draft-ietf-6man-rfc3484-revise-05 is correct and complete.  I have not seen (yet) any significant technical concerns raised.  The last of those were discussed and (we believe) resolved in Quebec.  Are there any more?

It appears that there is general agreement here, with possibly a few
technical/content nits that probably need to be sorted in a final
revision, raised by Dave and documented in message:
https://www.ietf.org/mail-archive/web/ipv6/current/msg14984.html

> The other is whether the WG believes we should publish an update, or a complete fresh version of RFC3484.  This was discussed previously in the WG and the update path preferred.  If a fresh version is now deemed more appropriate, I am fine to work on that with the other authors if required.

My understanding is that there is also general agreement here; that
this should be published as an update (after being re-organized a bit)
now, and then followed up with a replace (bis) I-D. As I have
previously stated; the changes in this update are needed and are
time-sensitive, the sooner this update can become an RFC the better.

> We just need a decision so we can progress this - it's been so close to release for a long time.  Many of the changes in the update have been implemented in a number of platforms already.

Agreed, let's get this done! =)

Cheers,
~Chris

PS - I don't want to step on any toes here, but I'd be happy to take a
stab at a revision based on the current feedback if the authors would
like, I could probably get it done by the end of next week, possibly
sooner.

> Tim

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 17 Jan 2012 21:39:45 +0900

Hi,

sorry for the delay.
I put together the remaining issues to be fixed in -06 version.

Several points,

- regarding the site-local deprecation, if I noticed only the examples
section should be updated. And, I'm now wondering if the examples
should be updated or not.

- regarding the informative reference, please tell me how exactly to
refer to them in informative way.

Let me have your quick look at this, before submission.

--
Arifumi Matsumoto
 NGN System Architecture Project
 NTT Service Integration Laboratories
 E-mail: [email-masked]
 TEL +81-422-59-3334 FAX +81-422-59-6364

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jan 2012 09:26:53 +1100

ULA need to be de-preferenced except for the local ULA prefixes.

Below is what I use in FreeBSD 8.  It keeps local traffic using
fd92:7065:b8e::/48 rather than using the PA address.  If you learn
a ULA destination address that is not local YOU DO NOT WANT TO USE
IT by default when you have another choice.

What you do want is for a interface when it learns a ULA address
to add the corresponding /48 prefix with a given precedence and a
unique label to the table if the prefix does not exist.  And
appropriate cleaning be done when no more interfaces exist in the
/48.  This may require a manual tag on table entries.

Mark

>   more /etc/ip6addrctl.conf 
#Prefix                          Prec Label     
::1/128                           50     0
::/0                              40     1     
2002::/16                         30     2        
::/96                             20     3        
::ffff:0.0.0.0/96                 35     4        
fd92:7065:b8e::/48                45     5 
fc00::/7                          5      6
> ifconfig nfe0 inet6
nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=82008<VLAN_MTU,WOL_MAGIC,LINKSTATE>
	inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5 
	inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf 
	inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 18 Jan 2012 11:22:08 +0900

Oops,

I attached an old version.
Here is the newer one.

On 2012/01/17, at 21:39, Arifumi Matsumoto wrote:

> <draft-ietf-6man-rfc3484-revise-06.txt>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jan 2012 15:52:07 +1300

> IT by default when you have another choice.

Not true if you have a VPN link to a business partner and you want
your traffic to that partner to use the ULA, which is routed via
the VPN, rather than a GUA that is routed via the Internet.

Not true if an enterprise uses multiple ULA prefixes internally
for some reason.

These cases will need explicit policy table entries if the default
is de-pref as you suggest.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jan 2012 15:11:42 +1100

> the VPN, rather than a GUA that is routed via the Internet.

Which doesn't fall under a *default* policy.  You would add the
partner's /48 to custom table and distribute it rather than use the
default.

> Not true if an enterprise uses multiple ULA prefixes internally

Again this doesn't fall under a *default* policy.
 
> is de-pref as you suggest.

And any ULA address that leaks, and they will, will cause back holes
to appear, similar to the way broken 6to4 does.  Fast retries,
similar to HE, will help somewhat but sensible defaults and knowing
when to override them work even better.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 23 Jan 2012 15:33:26 +0900

Mark,
thank you for your comment.

As you mention it, it should be less harmful to give the whole ULA
block a lower precedence value, if we assume ULA leakages will happen
here and there by DNS mis-configurations, address information exchange
in P2P applications, and so on.

Regarding communication between ULAs, such a network that really wants
to make use of multiple ULA blocks should have a way of controlling
address selection behavior of their hosts, such as policy table
configuration and DNS configuration.

The question is whether we can accept the appearance of macro in
the policy table.

         Prefix        Precedence Label
         ::1/128               60     0
         <YOUR ULA>:/48        50     1
         ::/0                  40     2
         ::ffff:0:0/96         30     3
         2002::/16             20     4
         2001::/32             10     5
         fc00::/7               5     6
         ::/96                  1    10
         fec0::/10              1    11
         3ffe::/16              1    12

    I assume the line of <YOUR ULA> will be interpreted as a line
    or lines of ULA prefix(es) that is attached to interface(s).

Another point is that a host has to maintain the ULA line in responses
to addition and deletion of the addresses.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Mon, 23 Jan 2012 18:09:47 +1100

> The question is whether we can accept the appearance of macro in

You also want the labels for each ULA/48 to be seperate.

	    <YOUR ULA>:/48        50     #

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Jan 2012 11:35:45 +0900

Hi,

> You also want the labels for each ULA/48 to be seperate.

Do we need to have different labels for ULAs ?

If ULAs are assigned to a host, the host can choose an appropriate
source ULA address because of the longest match rule.

>>        ::ffff:0:0/96         30     3

Another possibility is just the de-pref of the whole ULA block.

       Prefix        Precedence Label
       ::1/128               60     0
       ::/0                  40     2
       ::ffff:0:0/96         30     3
       2002::/16             20     4
       2001::/32             10     5
       fc00::/7               5     6
       ::/96                  1    10
       fec0::/10              1    11
       3ffe::/16              1    12

In this case, the problem Mark pointed out will not happen, but
ULA will not be preferred over IPv4 and IPv6 global addresses.
Do we really prefer ULA over these addresses ?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Jan 2012 13:54:20 +1100

In message <[email-masked]>, Arifumi Matsumoto 
> source ULA address because of the longest match rule.

That may be enough.

> Another possibility is just the de-pref of the whole ULA block.

Yes.  Think Homenet where you want *internal* connections to use
ULA rather than PA addresses.

Mark

---

From: Dave Thaler <[email-masked]>
Date: Sat, 28 Jan 2012 01:23:13 +0000

> >> Hmm sorry for being unclear, the technical part looked okay as far as
> >> I could tell, but as the quoted words from you, it will probably be
> >> more confusing to have two documents where the last one update/change
> >> the first one. Would be much better to have just one
> >> replacing/updating the old one.
> >
> > That was my first thought, but then I realised it would cause a lot of
> > delay, and I think getting these changes deployed is quite urgent.
> 
> I must agree, there is certainly an urgent need to fix the problems in the current
> RFC 3484, particularly around the handling of ULAs, etc.
> For one example; I am currently working on sorting out proper IPv6 support in
> UPnP and DLNA (targeting CE) and we have (effectively) nothing to point to for
> dynamic source address selection procedures.
> Since there appears to be consensus on the technical changes, is there a way to
> make the needed editorial changes and then advance to IETF last call (or a
> second WG last call at least)?

Resurrecting this thread in the hopes of resurrecting some energy on this draft...

It is not correct that we have consensus on the technical changes, since
I raised a number of technical issues in my review of the document (and
since only Brian and I reviewed, that's 50% of reviewers :)

That said, I think it would be easy to get consensus since I made specific
recommendations that I don't think should be controversial.   But in any case,
this would definitely need a second WGLC.

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jan 2012 11:30:45 +1300

On 2012-01-28 14:23, Dave Thaler wrote:
...
> this would definitely need a second WGLC.

True, but let's do it, since the market really needs this update.

   Brian