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

From: Dave Thaler <[email-masked]>
Date: Sat, 11 Feb 2012 02:41:38 +0000

I'm now working on an actual update to rfc3484 that would Obsolete
(not Update) it.   I found a couple more technical issues in so doing.
I also now believe it's faster to do the replacement than it is to
fix a delta-based document.

1) -revise documented the issue with Rule 9 of section 6, but does not
mention the same issue with Rule 8 of section 5, nor does it suggest a fix.
The proposed change to section 6 rule 9 used a "Netmask()" which was not
defined and indeed the term "mask" is not used with IPv6, only prefix length.
Instead of taking the proposed change, I propose to instead change the
definition of CommonPrefixLen() in section 2.2 as follows:

OLD (RFC 3484):
   We define the common prefix length CommonPrefixLen(A, B) of two
   addresses A and B as the length of the longest prefix (looking at the
   most significant, or leftmost, bits) that the two addresses have in
   common.  It ranges from 0 to 128.

NEW:
   We define the common prefix length CommonPrefixLen(S, D) of a source
   address S and a destination address D as the length of the longest
   prefix (looking at the most significant, or leftmost, bits) that the
   two addresses have in common, up to the length of S's prefix (i.e.,
   the portion of the address not including the interface ID).  For
   example, CommonPrefixLen(fe80::1, fe80::2) is 64.

2) Should ULAs be treated as site-local scope for purpose of the scope rules?

Consider the following two cases.

Destination Address Sorting: which should be preferred by default:
	a) a native IPv6 global destination address?
	b) a non-native ULA destination address that isn't in the same 
                 prefix as your own ULA (if any)?

I'd argue that (a) is the right answer.   The -revise draft's proposal 
would instead result in (b).

Source Address Sorting: which should be preferred by default when
sending to a site-local multicast address:
	a) a deprecated ULA source address?
	b) a non-deprecated link-local source address?

I'd argue that (b) is the right answer.  The -revise draft's proposal
would instead result in (a).

As such, I believe the correct fix is not to put fc00::/7 into the policy
table, but instead to update section 3.1 to say that we map ULAs to
multicast site-local scope.   The existing scope rules would then have
the effects I argue are the right answers above.

2)	Was RFC 3484 in error when it said IPv4-translatable addresses
should be treated as always in the "preferred" state?

We now know a lot more about IPv4-translatable addresses than
we (or I, anyway) did when 3484 was written, and RFC 6145 is the
current reference.   IPv4 translatable addresses are not necessarily
recognized as such by a host.  A host might get one from say DHCPv6
without knowing it's one, and that would be considered fine and normal.
However, the statement about being in the "preferred" state is somewhere
between unimplementable, and incorrect because the host is supposed
to go through DAD, etc.

Proposed fix:
OLD (RFC 3484):
   IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should
   be treated as having "preferred" (in the RFC 2462 sense)
   configuration status.

NEW:
   IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should
   be treated as having "preferred" (in the RFC 4862 sense)
   configuration status.

(An "IPv4-converted" address is not assigned to any interface, it's the
IPv6 representation of an IPv4 address assigned to someone's interface,
just like IPv4-mapped addresses except that IPv4-converted addresses
can appear on the wire.  See RFC 6145 for details.)

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 13 Feb 2012 18:12:40 +0000

One typo below...

> -----Original Message-----
> From: Dave Thaler
> Sent: Friday, February 10, 2012 6:42 PM
> To: Dave Thaler; Chris Grundemann; Brian E Carpenter
> Cc: Bob Hinden; Brian Haberman; [email-masked]
> Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
> 
> I also now believe it's faster to do the replacement than it is to fix a delta-
> based document.
> 
> Source Address Sorting: which should be preferred by default when sending
> to a site-local multicast address:
> I'd argue that (b) is the right answer.  The -revise draft's proposal would
> instead result in (a).

Above was backwards, should be:
I'd argue that (a) is the right answer.   The -revise draft's proposal
would instead result in (b).
 
> As such, I believe the correct fix is not to put fc00::/7 into the policy table, but
> instead to update section 3.1 to say that we map ULAs to
> We now know a lot more about IPv4-translatable addresses than we (or I,
> anyway) did when 3484 was written, and RFC 6145 is the
> recognized as such by a host.  A host might get one from say DHCPv6 without
> knowing it's one, and that would be considered fine and normal.
> between unimplementable, and incorrect because the host is supposed to go
> through DAD, etc.
> 
> Proposed fix:
> OLD (RFC 3484):
> IPv6 representation of an IPv4 address assigned to someone's interface, just
> like IPv4-mapped addresses except that IPv4-converted addresses can appear
> on the wire.  See RFC 6145 for details.)
> 
> -Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 13 Feb 2012 22:01:26 +0000

Yet another problem in draft-ietf-6man-rfc3484-revise...

Section 2.4 (Private IPv4 address scope):
[...]
>   The algorithm currently specified in RFC 3484 is based on the
>   assumption that a source address with a small scope cannot reach a
>   destination address with a larger scope.
[...]

The above sentence is simply not true, it was NOT based on such an
assumption at all.  It was based on the assumption that it was
less likely to work.   There's two reasons why it's less likely to work.
First, it might or might not be able to reach it (the text overstates
by saying it cannot... it was acknowledged that it may or may not).
Second, if it goes through a NAT, it might not work for protocols
that embed IP addresses in payloads.
[...]

>   Due to this assumption, in the presence of both a NATed private IPv4
>   address and a transitional address (like 6to4 or Teredo), the host
>   will choose the transitional IPv6 address to access dual-stack peers
>   [I-D.denis-v6ops-nat-addrsel].  Choosing transitional IPv6
>   connectivity over native IPv4 connectivity, particularly where the
>   transitional connectivity is unmanaged, is not considered to be
>   generally desirable.
>
>   This issue can be fixed by changing the address scope of private IPv4
>   addresses to global.

Section 10 of RFC 3484 contained many examples.   -revise contains
no such example of what it's talking about, so I have to guess.  Let's
look at 3 cases.

Case 1: 
 D set = { global IPv6, global IPv4 }
 S set = { Teredo IPv6, RFC1918 IPv4 }

Under RFC 3484 rules, Destination Address Selection would prefer
the Teredo connectivity under rule 2 (Prefer matching scope).

Under -revise rules, Destination Address Selection would still prefer
the Teredo connectivity under rule 6 (Prefer higher precedence),
since the precedence of the (non-Teredo) destination address
beats the precedence of the IPv4 address.   Hence -revise
does not change the behavior in this case.

Case 2:
 D set = { Teredo IPv6, global IPv4 }

Not an interesting case because Teredo addressing should be
disabled when a host has a global IPv4 address.

Case 3:
 D set = { global IPv4 = 1.2.3.4 }
 S set = { NAT-ed IPv4 = 10.2.3.4, global IPv4 = 128.66.3.4 }

Under RFC 3484 rules, Source Address Selection would prefer
the global IPv4 address under Rule 2(Prefer appropriate scope).
Under -revise rules, Source Address Selection would instead prefer 
the NAT'ed IPv4 under Rule 8 (Longest matching prefix).

This is broken.   I don't see a real case the proposed change
fixes, I only see real cases it breaks.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 13 Feb 2012 23:55:30 +0000

> Sent: Monday, February 13, 2012 2:01 PM
> To: Dave Thaler; 'Chris Grundemann'; 'Brian E Carpenter'
> Cc: [email-masked]'; 'Brian Haberman'; 'Bob Hinden'
> The above sentence is simply not true, it was NOT based on such an assumption
> at all.  It was based on the assumption that it was
> First, it might or might not be able to reach it (the text overstates by saying it
> cannot... it was acknowledged that it may or may not).
> Second, if it goes through a NAT, it might not work for protocols that embed IP
> addresses in payloads.
> [...]
> 
> no such example of what it's talking about, so I have to guess.  Let's look at 3
> cases.
> 
> Case 1:
> Under RFC 3484 rules, Destination Address Selection would prefer the Teredo
> connectivity under rule 2 (Prefer matching scope).
> 
> Under -revise rules, Destination Address Selection would still prefer the Teredo
> connectivity under rule 6 (Prefer higher precedence), since the precedence of
> the (non-Teredo) destination address

Dmitry Anipko pointed out that rule 5 (Prefer matching label) would cause
the -revise rules to prefer IPv4.  Still, I'd prefer a solution that doesn't solve
this problem by creating another one (case 3).   That is, we should fix a problem
rather than just move it around.

I'll think about this and  see if I can come back with a proposal.

-Dave

> Not an interesting case because Teredo addressing should be disabled when a
> host has a global IPv4 address.
> 
> Case 3:
> Under RFC 3484 rules, Source Address Selection would prefer the global IPv4
> address under Rule 2(Prefer appropriate scope).
> Under -revise rules, Source Address Selection would instead prefer the NAT'ed
> IPv4 under Rule 8 (Longest matching prefix).
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 15 Feb 2012 01:49:49 +0900

Dave,

one quick question below.

> the effects I argue are the right answers above.

So, you are suggesting to map ULAs(fc00::/7) to site-local scope also for unicast ?
Then, I don't see how the former case can be solved by this fix.
The ULAs should be chosen for both src and dst addresses, if they have smaller
scope than global addresses, right ?

Or, are you suggesting to map only ULAs that is in the same prefix to site-local scope ?

Best regards,

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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 15 Feb 2012 02:02:01 +0900

Dave,

another point below.

>> fixes, I only see real cases it breaks.

AFAIK, neither RFC 3484 nor -revise specifies source address selection algorithm
for an IPv4 destination address. Simply, it is out of scope of these documents.

Do you want to cover these issues in the revision ?

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2012 09:10:34 +1300

> On 2012/02/11, at 11:41, Dave Thaler wrote:

...
> scope than global addresses, right ?

IMHO we have to be very careful about messing with the formal scope of ULAs.
They are unambiguously defined *architecturally* as having global scope,
and address selection rules have to respect that (unless we make a major
architectural effort, since IMNSHO our whole concept of unicast scope is
broken).

In other words - in the unicast domain, ULAs have to stay global, and longest-
match or explicit rules are the only solution.

Multicast is a different matter, since site-local scope is well defined there.

> Or, are you suggesting to map only ULAs that is in the same prefix to site-local scope ?

Not needed; longest match takes care of that. The tricky case is where you
have several ULA prefixes in use on the same site.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Feb 2012 22:28:24 +0000

Comment in-line...

> Do you want to cover these issues in the revision ?

I agree with Arifumi's comment here, see the end of paragraph 3 of section 2: 
"Application of this specification to source address selection in an IPv4 network 
layer may be possible but this is not explored further here."

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Feb 2012 22:30:06 +0000

> that embed IP addresses in payloads.

I certainly agree that that wording can be improved.

Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 24 Feb 2012 15:13:59 +0900

Dave,

in Example section of draft-ietf-6man-rfc3484bis-00.txt, I found
the response to this issue of ULA scope.

10.6.  Configuring ULA Preference
...
   Since ULAs are defined to have a /48 site prefix, an implementation
   might choose to add such a row automatically on a machine with a ULA.

   It is also worth noting that ULAs are assigned global scope.  As
   such, the existence of one or more rows in the prefix policy table is
   important so that source address selection does not choose a ULA
   purely based on longest match:

   Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1
   Destination Address List: ff00:1
   Result: 2001:db8:1::1 (prefer matching label)

IMO, this implicit specification causes several problems.

First of all, if you leave it to implementation, this creates an
interoperability problem. In the sense that a site administrator,
an application developer, a network designer, have to take care of
the nodes with different address selection behavior.

Second,
when a user configures his policy table, the configured table is
overwritten by this implementation dependent policy injection behavior ?
Can the user suppress this behavior of policy injection ?
This issue should arise also when a policy distributing mechanism
is ready.

Kindest regards,

--
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: Dave Thaler <[email-masked]>
Date: Thu, 1 Mar 2012 02:20:58 +0000

> From: Arifumi Matsumoto [mailto:[email-masked]]
> Sent: Thursday, February 23, 2012 10:14 PM
> To: Brian E Carpenter
> Cc: Dave Thaler; Chris Grundemann; [email-masked]; Brian Haberman; Bob
> Hinden
> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
> 
> Dave,
> 
> in Example section of draft-ietf-6man-rfc3484bis-00.txt, I found the response to
> this issue of ULA scope.
> 
> First of all, if you leave it to implementation, this creates an interoperability
> problem. In the sense that a site administrator, an application developer, a
> network designer, have to take care of the nodes with different address
> selection behavior.

Are you arguing it should be mandatory, not optional?  (I'm guessing so based
on the previous discussion of "macros" in the table.)

But still, you have to take care of nodes with different address selection behavior
anyway if you allow heterogeneous hosts, since you'll have
a) hosts that don't do RFC 3484
b) hosts that do RFC 3484
c) hosts that do 3484bis

And even within a category above, the IPv4 source address selection behavior
will vary since that's not specified.

At best you can argue to minimize the problem as much as possible, but
you can't make it go away.
 
> Second,
> when a user configures his policy table, the configured table is overwritten by
> this implementation dependent policy injection behavior ?
> This issue should arise also when a policy distributing mechanism is ready.

Good questions.  Do you have suggested answers to those questions?
I might throw out a strawman of:

Any automatic rows added by the implementation as a result of address
acquisition MUST NOT override a row for the same prefix configured
via other means.   That is, rows can be added but never updated
automatically.   An implementation SHOULD provide a means for
an administrator to disable automatic row additions.

-Dave