Subject: [Softwires] 4rd Address Mapping - version-01

From: Rémi Després <[email-masked]>
Date: Thu, 22 Sep 2011 13:18:18 +0200

Alain, all,

We have just posted a new version of our I-D on the proposed 4rd Address Mapping.
It is available at
www.ietf.org/id/draft-despres-softwire-4rd-addmapping-01.txt

Our presentation will be based on THIS version, technically simpler than version -00.
Major differences and their justifications will be briefly explained.

Regards,
RD

---

From: Washam Fan <[email-masked]>
Date: Thu, 22 Sep 2011 22:06:31 +0800

Hi Remi,

I found this version is more clearer and simpler thanks to those
examples and diagrams.

I have 3 comments here:
1. You mentioned port-less layer-4 protocol in section 6, were you
refering to ICMP? IIRC, the echo request sequence can be seen as a
port to some extend. But it was not mentioned in the new version,
Would you explain why?
2. It seems to me you assumed rule ipv6 prefix length is shorter or
equals to 64. was that your intention? (I assume yes, otherwise 4rd
IID makes no sense)
3. Personally, I think it might be better if you move security
relevant text to Security Consideration section. I recall there was a
draft/RFC regarding to tunnel security, but i can not tell now. Would
be better to reference such a doc if it existed.

Thanks,
washam

2011/9/22 Rémi Després <[email-masked]>:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 22 Sep 2011 17:12:24 +0200

hi Washam,
Thank you for your remarks.
Answers inline.

> port to some extend. But it was not mentioned in the new version,

It is actually covered at the bottom of page 6 and beginning of page 7.
OK?
  
> equals to 64. was that your intention? (I assume yes, otherwise 4rd

Yes, certainly.
Rule IPV6 prefixes appear at the beginning of CE IPv6 prefixes, which have themselves at most 64 bits.

> relevant text to Security Consideration section.

Debatable, IMHO, but can be discussed.

> I recall there was a

Note that this draft is only about address mappings.
- It can apply to both double translations and tunnels
- Its port-set definition algorithm, taken alone, can also apply to other scenarios;

It is IMHO up to tunnel-based drafts to cover their specific security issues. 

Regards,
RD

---

From: Leaf yeh <[email-masked]>
Date: Sat, 24 Sep 2011 11:01:45 +0000

The following is my quick comments & questions on the new updated draft.

https://datatracker.ietf.org/doc/draft-despres-softwire-4rd-addmapping/?include_text=1

Section 6

   …Its CE IPv6 prefix, Rule IPv6 prefix, and Rule

   IPv4 prefix, are supposed to be respectively 2001:db4:4444:4000::/52,

   2001:db0::/28, and 192.32../12 (i.e. 0x602). …

C1. The 1st 3 hex of the Rule IPv4 prefix, 0x602, should turn to be 96.32.0.0/12, right?

Section 7

Item                        Hexadecimal Value        Nb of bits

   - IPv4 port          :            8488                      16

   - Derived

      Max Port-set ID   :             488                      12

   - IPv4 address       :      60244444                        32

   - Rule IPv4 prefix

      that matches this

      IPv4 address      :      602                             12

   - Resulting CE index :         44444488                     32

   - Rule IPv6 prefix

      of the Rule       :  20010DB                             28

   - Padding to 64 bits :                 0                     4

   - Resulting

      CE IPv6 address   :  20010DB44444488002005EFE00000000   128

   - Prefix routed

      to the CE         :  20010DB444444                       52
-------------------------------------------------

C2. I supposed the CE IPv6 address is associated with the CE index (including part of IPv4 address delegated & masked by the Rule IPv4 prefix + the fixed PSID) to identify the unique CE device, not associated the dynamic part of the IPv4 layer-4 port. Otherwise, there will be a bunch of IPv6 address associated with one CE.

Q1. Any more words for the understanding on the case definition of double-translation?

Best Regards,

Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Thursday, September 22, 2011 7:18 PM
To: Softwires-wg
Subject: [Softwires] 4rd Address Mapping - version-01

Alain, all,

It is available at

Regards,

RD

Softwires mailing list

[email-masked]

---

From: Leaf yeh <[email-masked]>
Date: Sat, 24 Sep 2011 11:03:12 +0000

Section 6

Section 7

   - IPv4 port          :            8488                      16

   - Derived

      Max Port-set ID   :             488                      12

   - Rule IPv4 prefix

      that matches this

      IPv4 address      :      602                             12

   - Rule IPv6 prefix

      of the Rule       :  20010DB                             28

   - Resulting

   - Prefix routed

Best Regards,

Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Thursday, September 22, 2011 7:18 PM
To: Softwires-wg
Subject: [Softwires] 4rd Address Mapping - version-01

Alain, all,

It is available at

Regards,

RD

Softwires mailing list

[email-masked]

---

From: Jacni Qin <[email-masked]>
Date: Mon, 26 Sep 2011 07:17:47 +0800

On 9/24/2011 7:01 PM, Leaf yeh wrote:
> ...Its CE IPv6 prefix, Rule IPv6 prefix, and Rule
>
>    2001:db0::/28, and 192.32../12 (i.e. 0x602). ...
>
> C1. The 1^st 3 hex of the Rule IPv4 prefix, 0x602, should turn to be 
> 96.32.0.0/12, right?
>
> Section 7
>
> C2. I supposed the CE IPv6 address is associated with the CE index 
> (including part of IPv4 address delegated & masked by the Rule IPv4 
> prefix + the fixed PSID) to identify the unique CE device, not 
> associated the dynamic part of the IPv4 layer-4 port. Otherwise, there 
> will be a bunch of IPv6 address associated with one CE.
>
It is used to route packets to the unique CE, but the CE index in the CE 
IPv6 address is derived from, for example, the IPv4 destination address 
+ Port.

> Q1. Any more words for the understanding on the case definition of 
Please refer to the 4rd-T draft or other translation based approaches.

Cheers,
Jacni

---

From: Leaf yeh <[email-masked]>
Date: Mon, 26 Sep 2011 01:54:10 +0000

Jacni - It is used to route packets to the unique CE, but the CE index in the CE IPv6 address is derived from, for example, the IPv4 destination address + Port.

I thought the CE index (the fixed part of the rule), not the max CE index (which includes the dynamic part), could derived from the IPv4 destination address + Port in the received IPv4 packets at BR.

Best Regards,

Leaf

________________________________
发件人: Jacni Qin [[email-masked]]
发送时间: 2011年9月26日 7:17
到: Leaf yeh
Cc: Rémi Després; Softwires-wg
主题: Re: [Softwires] 4rd Address Mapping - version-01

Section 6

Section 7

   - IPv4 port          :            8488                      16

   - Derived

      Max Port-set ID   :             488                      12

   - Rule IPv4 prefix

      that matches this

      IPv4 address      :      602                             12

   - Rule IPv6 prefix

      of the Rule       :  20010DB                             28

   - Resulting

   - Prefix routed

It is used to route packets to the unique CE, but the CE index in the CE IPv6 address is derived from, for example, the IPv4 destination address + Port.

Cheers,
Jacni

Best Regards,

Leaf

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Thursday, September 22, 2011 7:18 PM
To: Softwires-wg
Subject: [Softwires] 4rd Address Mapping - version-01

Alain, all,

It is available at

www.ietf.org/id/draft-despres-softwire-4rd-addmapping-01.txt<http://www.ietf.org/id/draft-despres-softwire-4rd-addmapping-01.txt>

Regards,

RD

Softwires mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Jacni Qin <[email-masked]>
Date: Mon, 26 Sep 2011 15:12:56 +0800

On 9/26/2011 9:54 AM, Leaf yeh wrote:
>
> Jacni - It is used to route packets to the unique CE, but the CE index
> in the CE IPv6 address is derived from, for example, the IPv4
> destination address + Port.
>
> I thought the CE index (the fixed part of the rule), not the max CE
> index (which includes the dynamic part), could derived from the IPv4
> destination address + Port in the received IPv4 packets at BR.
>
The max CE index (formed based on the "max PSID" which is of 12 bits got
from the port, 12 bits may probably be longer than the length of the
real PSID of the target CE) is used by sending CE when forming the IPv6
address of the target CE based on the IPv4 destination address + port.

Cheers,
Jacni

> Best Regards,
>
> Leaf
>
> ------------------------------------------------------------------------
> *发件人:* Jacni Qin [[email-masked]]
> *发送时间:* 2011年9月26日 7:17
> *到:* Leaf yeh
> *Cc:* Rémi Després; Softwires-wg
> *主题:* Re: [Softwires] 4rd Address Mapping - version-01
>
>
>
>> Max Port-set ID: 488 12
>> associated the dynamic part of the IPv4 layer-4 port. Otherwise,
>> there will be a bunch of IPv6 address associated with one CE.
>>
> It is used to route packets to the unique CE, but the CE index in the
> CE IPv6 address is derived from, for example, the IPv4 destination
> address + Port.
>

---

From: GangChen <[email-masked]>
Date: Tue, 27 Sep 2011 00:27:14 +0800

> It is actually covered at the bottom of page 6 and beginning of page 7.

I guess what Washam mentioned is why example in section 6 would not
demonstrate how to use such ID bits in ICMP message?

---

From: Tetsuya Murakami <[email-masked]>
Date: Tue, 27 Sep 2011 22:36:11 -0700

Hi Remi,

I have one question about your new address mapping draft.

In the draft, you mentioned the special IID can be used for distinguishing 4rd packets from other IPv6 packet whose destination start with CE IPv6 prefixes.

But I think it is difficult to distribute the IPv6 prefix matching to the assigned Domain IPv6 prefix. Here is one example.

CE IPv6 Prefix:
+----------------------------+------------------+
| Domain IPv6 Prefix (36bit) | CE index (20bit) |
+----------------------------+------------------+

Domain IPv4 Prefix:
+--------------+
|   16 bits    |
+--------------+

In this case, the first 16bits of CE index can be embedded in the last 16bits of IPv4 address followed by Domain IPv4 prefix. And then the remaining 4bits of CE index can be embedded as PSID followed by 4bit port head.

At the BR, BR can generate the destination IPv6 address from the IPv4 destination and the destination port number as shown below.

<---------------------------------- 64bit --------------------------------------->
+----------------------------+--------------------------------+------------------+
| Domain IPv6 Prefix (36bit) | suffix of IPv4 address (16bit) | MAX PSID (12bit) |
+----------------------------+--------------------------------+------------------+
<---------------- CE IPv6 Prefix (56bit)--------------------------->

PSID can be derived from the port number after removing the first 4bit even though the length of the actual PSID is only 4bit. In this case, CPE should terminate the packet whose IPv6 destination is matched to CE IPv6 Prefix and then process the decapsulation for 4rd. So, I think this means that any IPv6 prefix matching to CE IPv6 Prefix can be terminated at 4rd functionality in CE. For this, even though CE IPv6 Prefix can be delegated to the CE, CE can not delegate any IPv6 prefixes matching to CE IPv6 Prefix to any hosts connected on the LAN side of the CE. Usually, if the CE can get an IPv6 prefix whose length is 56bit, CE can delegate an IPv6 prefix having the different prefix length (i.e. 64bit) to the hosts locating on the LAN side of the CE. But I don't think it can be working because the IPv6 destination matching to CE IPv6 prefix (delegated prefix) should be terminated at CPE for 4rd processing. So, in order to provide Dual-stack for the hosts locating on the LAN side of the CE, an additional IPv6 prefix different from CE IPv6 Prefix needs to be delegated.

Is my understand correct?

Thanks,
Tetsuya Murakami

---

From: Jacni Qin <[email-masked]>
Date: Wed, 28 Sep 2011 15:14:56 +0800

hi Tetsuya,

Inline please,

On 9/28/2011 1:36 PM, Tetsuya Murakami wrote:
> In the draft, you mentioned the special IID can be used for 
> distinguishing 4rd packets from other IPv6 packet whose destination 
> start with CE IPv6 prefixes.
>
> But I think it is difficult to distribute the IPv6 prefix matching to 
> the assigned Domain IPv6 prefix. Here is one example.
>
> CE IPv6 Prefix:
> In this case, the first 16bits of CE index can be embedded in the last 
> 16bits of IPv4 address followed by Domain IPv4 prefix. And then the 
> remaining 4bits of CE index can be embedded as PSID followed by 4bit 
> port head.
>
> At the BR, BR can generate the destination IPv6 address from the IPv4 
> destination and the destination port number as shown below.
>
> PSID can be derived from the port number after removing the first 4bit 
> even though the length of the actual PSID is only 4bit.
The last 8 bits can be just ignored, but the first 56 bits are still 
unique and enough for routing.

> In this case, CPE should terminate the packet whose IPv6 destination 
> is matched to CE IPv6 Prefix and then process the decapsulation for 
> 4rd. So, I think this means that any IPv6 prefix matching to CE IPv6 
> Prefix can be terminated at 4rd functionality in CE.
If only talking about encapsulation approach, the CE can check the next 
header to see whether the packet is for 4rd (of course, the tunneling by 
hosts in LAN may not be allowed in this case).
While, generally to be compatible with double translation, the 4rd IID 
can be employed.
That is, after receiving an packet, the CE will check whether the IPv6 
destination address matches its delegated prefix, and a 4rd IID exists. 
if so, the packet will be processed by 4rd functionality. Otherwise, the 
packet will be routed natively to some host attached in LAN.

> For this, even though CE IPv6 Prefix can be delegated to the CE, CE 
> can not delegate any IPv6 prefixes matching to CE IPv6 Prefix to any 
> hosts connected on the LAN side of the CE. Usually, if the CE can get 
> an IPv6 prefix whose length is 56bit, CE can delegate an IPv6 prefix 
> having the different prefix length (i.e. 64bit) to the hosts locating 
> on the LAN side of the CE. But I don't think it can be working because 
> the IPv6 destination matching to CE IPv6 prefix (delegated prefix) 
> should be terminated at CPE for 4rd processing. So, in order to 
> provide Dual-stack for the hosts locating on the LAN side of the CE, 
> an additional IPv6 prefix different from CE IPv6 Prefix needs to be 
> delegated.
Please see my comments above, the 4rd and IPv6 services can share the 
same delegated IPv6 prefix.

Cheers,
Jacni

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Sep 2011 20:10:40 +0200

>> In this case, CPE should terminate the packet whose IPv6 destination is matched to CE IPv6 Prefix and then process the decapsulation for 4rd. So, I think this means that any IPv6 prefix matching to CE IPv6 Prefix can be terminated at 4rd functionality in CE.
> If only talking about encapsulation approach, the CE can check the next header to see whether the packet is for 4rd (of course, the tunneling by hosts in LAN may not be allowed in this case). 
> While, generally to be compatible with double translation, the 4rd IID can be employed.
> That is, after receiving an packet, the CE will check whether the IPv6 destination address matches its delegated prefix, and a 4rd IID exists. if so, the packet will be processed by 4rd functionality. Otherwise, the packet will be routed natively to some host attached in LAN.
> 
>> For this, even though CE IPv6 Prefix can be delegated to the CE, CE can not delegate any IPv6 prefixes matching to CE IPv6 Prefix to any hosts connected on the LAN side of the CE. Usually, if the CE can get an IPv6 prefix whose length is 56bit, CE can delegate an IPv6 prefix having the different prefix length (i.e. 64bit) to the hosts locating on the LAN side of the CE. But I don't think it can be working because the IPv6 destination matching to CE IPv6 prefix (delegated prefix) should be terminated at CPE for 4rd processing. So, in order to provide Dual-stack for the hosts locating on the LAN side of the CE, an additional IPv6 prefix different from CE IPv6 Prefix needs to be delegated.
> Please see my comments above, the 4rd and IPv6 services can share the same delegated IPv6 prefix.

I would be tempted to suggest that we write a "an implementation MUST NOT make this assumption" in the MAP draft.
and that we in IETF documents write this as if there is a prefix reserved for address mapping.
in the general case there is no way to guarantee that a host doesn't pick the same IID. and we'll have to specify how this would work with DAD and proxy ND. I'd rather not. left up to the implementor is my suggestion...

cheers,
Ole

---

From: Jacni Qin <[email-masked]>
Date: Thu, 29 Sep 2011 09:20:21 +0800

> in the general case there is no way to guarantee that a host doesn't pick the same IID. and we'll have to specify how this would work with DAD and proxy ND. I'd rather not. left up to the implement…
Taking the EUI-64 into account, a careful design of the 4rd IID can make 
the probability of conflicts quite low. Then as you mentioned, DAD would 
further reduce it.
Anyway, that's not to say I'm in favor of this design, the reason I see, 
of doing this is just to accommodate the double translation while not 
affect at all the IPv6 addressing (a reserved prefix? no ...).

Cheers,
Jacni

---

From: Ole Troan <[email-masked]>
Date: Thu, 29 Sep 2011 08:00:53 +0200

Jacni,

> Taking the EUI-64 into account, a careful design of the 4rd IID can make the probability of conflicts quite low. Then as you mentioned, DAD would further reduce it.
> Anyway, that's not to say I'm in favor of this design, the reason I see, of doing this is just to accommodate the double translation while not affect at all the IPv6 addressing (a reserved prefix? no ...).

the DAD/ND redirect solution would fail in the routed home case. i.e. the case where there is multiple levels of routers in the network.
that's why I think the recommendation should be to use one /64 of the delegated prefix to the translation "pool".

cheers,
Ole

---

From: Jacni Qin <[email-masked]>
Date: Thu, 29 Sep 2011 14:54:03 +0800

Hi,

> the DAD/ND redirect solution would fail in the routed home case. i.e. the case where there is multiple levels of routers in the network.
ok, I get your case.

Cheers,
Jacni

---

From: Rémi Després <[email-masked]>
Date: Thu, 29 Sep 2011 20:42:47 +0800

Hi Tetsuya-san  and Jacni,

Please see inline.

Le 28 sept. 2011 à 15:14, Jacni Qin a écrit :

>> PSID can be derived from the port number after removing the first 4bit even though the length of the actual PSID is only 4bit.
> The last 8 bits can be just ignored, but the first 56 bits are still unique and enough for routing.
> 

Same understanding.
Thanks Jacni.

> While, generally to be compatible with double translation, the 4rd IID can be employed.

Actually, having a recognizable format for 4rd addresses makes it possible for hosts behind a 4rd CE to use any other IPv4-in-IPv6 encapsulation that 4rd without their packets being (inappropriately) processed as 4rd packets by the CE.

With a 4rd-recognizable IID, there is a guarantee that 4rd will never interfere with any non-4rd protocol.  

OK?

Thats AFAIK an important feature.
I remember a discussion with Wojciech about this, which maybe he could confirm.

RD

---

From: Ole Troan <[email-masked]>
Date: Thu, 29 Sep 2011 14:53:08 +0200

Remi,

> I remember a discussion with Wojciech about this, which maybe he could confirm.

not so much so for encapsulation. since the 4rd tunnel end point address is one of the CE's own addresses, the interface-id only matters for pretty printing and if features/classifiers are applied in the middle of the tunnel.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 29 Sep 2011 21:17:19 +0800

> and that we in IETF documents write this as if there is a prefix reserved for address mapping.

No need for that AFAIK (see below).

> in the general case there is no way to guarantee that a host doesn't pick the same IID.

Well, "no guarantee"...  unless a safe way of doing it is specified!
And this is already the case with 4rd-addmapping-01.
(If you would keep doubts after a careful check, please share your understanding.)
 
The modified format discussed in Beijing with Xing Li, Congxiao Bao, and Wojciech Dec, to be documented soon, will have the same property.

> and we'll have to specify how this would work with DAD and proxy ND. I'd rather not.

> left up to the implementor is my suggestion...

No need for that (see above).

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 29 Sep 2011 21:33:37 +0800

> the DAD/ND redirect solution would fail in the routed home case. i.e. the case where there is multiple levels of routers in the network.

Could you document more why you think that DAD/ND would fail if IPv6 addresses used to reach 4rd CEs would have a 4rd-distinguishable IID?

> that's why I think the recommendation should be to use one /64 of the delegated prefix to the translation "pool".

This would defeat one important objective: possible operation without ANY impact of IPv4 on IPv6 prefixes delegated to CEs.

As such, this would be AFAIK a step backward.

RD

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 29 Sep 2011 17:27:18 +0200

On 29/09/2011 14:53, "Ole Troan" <[email-masked]> wrote:

>> Actually, having a recognizable format for 4rd addresses makes it possible
>> for hosts behind a 4rd CE to use any other IPv4-in-IPv6 encapsulation that
>> 4rd without their packets being (inappropriately) processed as 4rd packets by
>> the CE.
>> 
> not so much so for encapsulation. since the 4rd tunnel end point address is
> one of the CE's own addresses, the interface-id only matters for pretty
> printing and if features/classifiers are applied in the middle of the tunnel.

The v4-address in the interface-id matters for a) the address matching
features b) consistency with rfc6052 esp in the 1:1 address mapped case.

-Woj.

---

From: Ole Troan <[email-masked]>
Date: Thu, 29 Sep 2011 19:52:56 +0200

Remi,

> Could you document more why you think that DAD/ND would fail if IPv6 addresses used to reach 4rd CEs would have a 4rd-distinguishable IID?

this is the translation case for a routed home. DAD/ND wouldn't be done on any of the links the dIVI CE was connected to.
for 4rd this isn't a problem since the packets are destined to the 4rd CE. the dIVI CE has to intercept packets not destined for itself.
in that case it would make sense to reserve a prefix for that purpose.
same as the 4rd CE address comes out of a /64 used for numbering internal interfaces on the CE.

> As such, this would be AFAIK a step backward.

I don't see that?

I thought this discussion started out with the case where IPv6 hosts were sharing the same prefix as is used for translated addresses.
I'm pointing out that this isn't a good idea. and I don't see why we need to describe that case in any of our documents.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 29 Sep 2011 19:58:42 +0200

> The modified format discussed in Beijing with Xing Li, Congxiao Bao, and Wojciech Dec, to be documented soon, will have the same property.

there are no guarantees, and no safe way of doing that.
there is no enforcement of global uniqueness of interface ids.
e.g. the use of longer than /64 prefixes, manual configuration.
you have a high probability of it being unique. and as long as it is only used for pretty printing and troubleshooting, then do you care?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 30 Sep 2011 10:41:34 +0800

> you have a high probability of it being unique. and as long as it is only used for pretty printing and troubleshooting, then do you care?

Still, the Modified EUI-64 format of RFC 4291 has been designed to ensure unicity of these Universal-scope IIDs.
True, a user can manually configure an EUI-64 IID that he shouldn't. The confusion that results is then his responsibility.
The same applies if a host behind a 4rd CE configures a 4rd IID: it won't be reachable from the Internet. 

Possibility of misconfiguration MUST NOT be a reason to give up specifying formats that work in absence of misconfigurations (as done with the modified EUI-64 format of RFC 4291).

>> No need for that (see above).

Confirmed because of the above.

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Fri, 30 Sep 2011 13:20:53 +0200

Remi,

> Possibility of misconfiguration MUST NOT be a reason to give up specifying formats that work in absence of misconfigurations (as done with the modified EUI-64 format of RFC 4291).

that's a property that was highly speculative 15 years ago when it was specified and a property that has never been verified.
but, let me turn the question around. what are the requirements for a globally unique interface-id? how is it going to be used?
both for encapsulation and translation? is it expected that routers have to make forwarding decisions on an interface-id?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 30 Sep 2011 14:19:44 +0800

Le 30 sept. 2011 à 19:20, Ole Troan a écrit :

> both for encapsulation and translation?

In both cases, the CE node can recognize 4rd packets, and process them as such, without preempting any IID value that might be a legitimate value for a host behind the CE.

> is it expected that routers have to make forwarding decisions on an interface-id?

No.
Ordinary routers are concerned with IIDs only on destination links but here, like with 6to4 and 6rd, there is no last link where the IID is exploited.

RD

---

From: Ole Troan <[email-masked]>
Date: Fri, 30 Sep 2011 15:48:33 +0200

Remi,

> Ordinary routers are concerned with IIDs only on destination links but here, like with 6to4 and 6rd, there is no last link where the IID is exploited.

you didn't quite answer my question.
let us get back to the starting point. what are you trying to achieve by having a special IID?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 30 Sep 2011 17:43:10 +0800

Le 30 sept. 2011 à 21:48, Ole Troan a écrit :
...

>>> what are the requirements for a globally unique interface-id? how is it going to be used?

This is my answer to your first (double) question.
If it is not enough, as suggested below, please explain what you don't understand.

Then, maybe, Wojciech could explain more clearly for you.

>> Ordinary routers are concerned with IIDs only on destination links but here, like with 6to4 and 6rd, there is no last link where the IID is exploited.

This is my answer to your second question.

> you didn't quite answer my question.

???

> let us get back to the starting point. what are you trying to achieve by having a special IID?

Please, see my comment about my first answer above.

RD

---

From: Ole Troan <[email-masked]>
Date: Fri, 30 Sep 2011 22:31:56 +0200

Remi,

> If it is not enough, as suggested below, please explain what you don't understand.

I specifically do not want a solution that changes forwarding behaviour for _all_ IPv6 packets.
e.g. looking at 24 bits in the middle of an IPv6 address is such a change.

I don't understand what requirements you are basing this 'solution' on.
if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of the delegated prefix. then why do you need any of that?
note that I'm not arguing against having a defined IID for dIVI/4rd, that's nice for pretty printing like what we do for ISATAP.

cheers,
Ole