Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 (was: Inapplicability of MAP-T+E to sites that have already assigned subnet ID = 0)

From: Ole Trøan <[email-masked]>
Date: Mon, 23 Jul 2012 10:55:14 +0200

Remi,

a site already using subnet 0 may require renumbering. would you be satisfied if the draft said so?

cheers,
Ole

On Jul 23, 2012, at 10:39 , softwire issue tracker wrote:

> #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0
> 
> Changes (by remi.despres@…):
> 
> * status:  closed => reopened
> * resolution:  invalid =>
> 
> 
> Comment:
> 
> Acknowledged: "exclusive use" of subnet 0 is improper since only one or
> several interface IDs are exclusive to MAP (several if the site is
> assigned an IPv4 prefix). Yet:
> 1. If a site uses subnet 0, and one of its host uses a MAP-exclusive
> interface ID (which, although unlikely, is possible), a conflict appears
> when MAP gets activated.
> 2. By avoiding any restriction on subnet 0 (e.g. with the V octet of 4rd),
> one avoids to depend on "further operator input" before considering that
> all needs are covered.
> 
> -- 
> ----------------------------------+----------------------------------------
> Reporter:  despres.remi@…        |       Owner:  draft-ietf-softwire-map@…
>    Type:  defect                |      Status:  reopened
> Priority:  critical              |   Milestone:
> Component:  map                   |     Version:
> Severity:  Active WG Document    |  Resolution:
> Keywords:  map-t map-e subnet-   |
> ID                              |
> ----------------------------------+----------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/softwire/trac/ticket/5#comment:3>
> softwire <http://tools.ietf.org/softwire/>
>

---

From: Ole Trøan <[email-masked]>
Date: Tue, 24 Jul 2012 12:46:28 +0200

> 1. No, 4rd doesn't have the same problem as MAP concerning sites that use
> subnet 0.
> Wojciech, if you see a reason why a site should renumber its subnet 0 to
> use 4rd, please explain.

because no-one will ever do this?

gomlefisk: otroan$ sudo ifconfig en1 inet6 2001:db8:0:0:0300::1/64
gomlefisk: otroan$ ifconfig en1
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1400
	ether 00:26:bb:1a:77:2e 
	inet6 fe80::226:bbff:fe1a:772e%en1 prefixlen 64 scopeid 0x6 
	inet 10.147.112.88 netmask 0xfffffc00 broadcast 10.147.115.255
	inet6 2001:db8::300:0:0:1 prefixlen 64 
	media: autoselect
	status: active
gomlefisk: otroan$ 

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Wed, 25 Jul 2012 09:55:50 +0200

Remi,

> Assuming that details that follow mean that an expert can configure a node with an address that isn't unauthorized by any RFC, and in particular a 4rd-reserved address, that's acknowledged. 
> But nothing specific needs to be done, in 4rd not more than in any specification, to make hand-configured unauthorized addresses to work properly. 
> 
> The difference between 4rd and MAP, in this respect, is as you know that MAP addresses can conflict with *authorized* host addresses. This is AFAIK the reason for your suggesting that sites that use subnet 0 be renumbered to support MAP.

just like any interface address can conflict with any other.
MAP uses a single address out of the first subnet in a delegation. the probability of collision even if it was shared with native hosts is reasonably small.

your view of the effect of reserving some bits in the middle of the interface-id for the purpose of 4rd seems quite overstated to me. nor do I follow your use of "authorized / unauthorized" interface-ids.

the solution proposed in MAP may not be perfect. it is a tradeoff. 4rd suggests another tradeoff that in my view, has much wider consequences. take it to 6man.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Jul 2012 15:47:40 +0200

RD

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Jul 2012 15:47:55 +0200

Le 2012-07-25 à 09:55, Ole Trøan a écrit :

> the solution proposed in MAP may not be perfect. it is a tradeoff.

> 4rd suggests another tradeoff that in my view, has much wider consequences.

Such wider consequences haven't been identified so far, despite the fact that the subject has been around for quite some time, and despite that the varied origins of supporters of the design.

> take it to 6man.

6man has to be involved, sure, but Softwire should first be clear about the purpose, and possible drawbacks if any.
If you see such drawbacks, please clarify.

Thanks,
RD

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 25 Jul 2012 13:56:11 +0000

On 25/07/2012 15:47, "Rémi Després" <[email-masked]> wrote:

>Assuming that details that follow mean that an expert can configure a
>node with an address that isn't unauthorized by any RFC, and in
>particular a 4rd-reserved address, that's acknowledged.
>But nothing specific needs to be done, in 4rd not more than in any
>specification, to make hand-configured unauthorized addresses to work
>properly. 
>
>The difference between 4rd and MAP, in this respect, is as you know that
>MAP addresses can conflict with *authorized* host addresses. This is
>AFAIK the reason for your suggesting that sites that use subnet 0 be
>renumbered to support MAP.

There is no such thing as an "authorized" host address. Duplicate address
detection is around for a reason, and also applies here.

By means of the V-octet, seeking to "appropriate" a part of all v6 address
space for 4rd, or any other device class to deal with a remote case of a
duplicate, which may still happen, seems overdone. In any case this looks
to be a 6man consideration.

-Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 25 Jul 2012 13:59:34 +0000

On 25/07/2012 15:47, "Rémi Després" <[email-masked]> wrote:

>
>
>
>> take it to 6man.
>
>6man has to be involved, sure, but Softwire should first be clear about
>the purpose, and possible drawbacks if any.

Here's one:
I'd like my <insert name of your favorite device class> to be guaranteed
*never ever* to conflict. Can I also get a V octet for <$my_device_class>?

-Woj.

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Jul 2012 16:11:15 +0200

> detection is around for a reason, and also applies here.

Well, this was to mean conforming to the "IP Version 6 Addressing Architecture" (RFC 4291).
Will try to be even more precise next time!

> space for 4rd,

It seems that, if you did read 4rd-03, you misunderstood the top of page 20.
it explains that nothing more than routing on prefixes as usual is needed to reach CE functions.
If I misunderstood your point about "appropriate a part of all v6 addresses", thanks for explaining.  

> or any other device class to deal with a remote case of a
> duplicate, which may still happen, seems overdone.

> In any case this looks

Same answer as to Ole:
"6man has to be involved, sure, but Softwire should first be clear about the purpose, and possible drawbacks if any."

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Jul 2012 16:13:34 +0200

> *never ever* to conflict. Can I also get a V octet for <$my_device_class>?

Sorry I couldn't decipher this.

RD

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 27 Jul 2012 16:20:45 +0200

> Sorry I couldn't decipher this.

How many V-octets do you think the IETF should assign, and why should the
V-octed belong to your proposed device/use-category? One may want the
V-octet to be used for "Next gen TVs", etc.
This is a problem & discussion for 6man, which has been said before...

-Woj.

---

From: Rémi Després <[email-masked]>
Date: Fri, 27 Jul 2012 17:01:13 +0200

Le 2012-07-27 à 16:20, Wojciech Dec a écrit :

> How many V-octets do you think the IETF should assign, and why should the V-octed belong to your proposed device/use-category? One may want the V-octet to be used for "Next gen TVs", etc.

1.
Well, the term "V octet" only identifies a particular value of the interface ID first octet.
"u" octet identifies another value of this same octet (but a value that, contrary to the V-octet value, can be found in local-scope addresses, and therefore isn't reserved).
What name NNN will be given to this field in general (independently of its reserved values) remains open. 
I agree that this is is a 6man matter.

2.
You ask how many values of the NNN field the IETF should assign in the future. 
This is is obviously uncertain. OTOH, What is sure is that, with 6 free bits and only assigned value for V, there is plenty room for future uses, especially since:
- no other use has been identified in 14 years
- one future value can be reserved to identify an extended format, thus largely increasing the number of reservable patterns.

3.
If no WG would be allowed to propose using the extension mechanism of RFC2373/4291, what, in your understanding,  would be its purpose?

RD