Subject: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routing in hub&spoke topology

From: Rémi Després <[email-masked]>
Date: Tue, 7 Feb 2012 11:13:11 +0100

Hello Ole, Tetsuya-san, Wojciech,

In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces its dual-stack routing by IPv6-only routing.
For this, independently from the number of IPv4 prefixes it has to support, it uses only one mapping rule.
(By replacing each IPv4 route by an equivalent IPv6 route, it ensures that all customers keep their IPv4 addresses.)

For this to work, the 4rd-U draft has a bit that, in the hub&spoke case, differs between CE-to-BR and BR-to-CE directions. Thus, packets sent to a CE take different routes depending on whether sent by a CE or a BR.

I don't see how the equivalent could work with the MAP documents you edited.
Is it that such a use case is out of scope for MAP?
Or did I miss something?

Cheers,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 7 Feb 2012 13:07:40 +0100

Hi Remi-san,

> (By replacing each IPv4 route by an equivalent IPv6 route, it ensures that all customers keep their IPv4 addresses.)

I don't think that it could work as you explained in that section. For example, the BR would need to check a received packet from a CE whether it has correct source address in mapping rule or not. It means that the BR must know all address mappings for CE between IPv4 addresses and IPv6 prefixes. Is it correct understanding? 

I think that operators who already deploy such dual-stack network is supposed that they have address mapping table, they can provision each CE individually, and also they are capable to distribute the default mapping rule since they should install it into the CEs. In that situation, what's the motivation of why the operator want to provision with only default mapping rule?

cheers,
--satoru

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

---

From: Ole Trøan <[email-masked]>
Date: Tue, 7 Feb 2012 13:16:35 +0100

Remi,

> Is it that such a use case is out of scope for MAP?

injecting IPv4 routing into the IPv6 routing table is considered a bad idea. that was what caused Automatic tunnelling and IPv4 compatible address in RFC1933 to be deprecated.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Feb 2012 13:49:14 +0100

> injecting IPv4 routing into the IPv6 routing table is considered a bad idea. that was what caused Automatic tunnelling and IPv4 compatible address in RFC1933 to be deprecated.

- Reference?
- Should we take it, then, that you reject moving from DS routing to IPV6-only routing without address/prefix changes as a use case you are interested in?

RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Feb 2012 14:03:18 +0100

> I don't think that it could work as you explained in that section. For example, the BR would need to check a received packet from a CE whether it has correct source address in mapping rule or not.…

Ingress filtering of the domain has checked that the IPv6 source starts with the delegated IPv6 prefix, a /112 which includes the IPv4 address. In the 4rd-E case, the BR checks that the source address in the IPv4 header matches that of the IPv6 address. There is therefore no need for the BR to know all IPv4 prefixes. At its IPv4 interface, all received packets start with one of them. At its IPv6 interface, all packets it receives have an embedded address that starts with one of these prefixes. 

> I think that operators who already deploy such dual-stack network is supposed that they have address mapping table,

I would rather suppose that ISPs that have added IPv6-prefix delegation, say /56s, to an existing IPv4 network did it without mixing their IPv6 plan with their IPv4 prefixes.
I am ready, however, to look seriously at individual cases where choices were different.

Regards,
RD

> they can provision each CE individually, and also they are capable to distribute the default mapping rule since they should install it into the CEs. In that situation, what's the motivation of why the operator want to provision with only default mapping rule?
> 
> cheers,
> --satoru
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 7 Feb 2012 08:18:06 -0500

> the 4rd-E case, the BR checks that the source address in the IPv4 header matches that of the IPv6 address. 

Could this check (and filtering) be done without incurring a performance penalty? 

Cheers,
Rajiv

Sent from my Phone

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Feb 2012 14:28:10 +0100

> Could this check (and filtering) be done without incurring a performance penalty? 

Yes indeed..
Consistency check between source IPv4 address and source IPv6 address is always part of encapsulation solutions (translation or header-mapping solutions are not concerned).
They are needed to avoid introducing vulnerability to spoofing attacks.

Cheers,
RD

---

From: Ole Trøan <[email-masked]>
Date: Tue, 7 Feb 2012 14:40:04 +0100

Remi,

>> injecting IPv4 routing into the IPv6 routing table is considered a bad idea. that was what caused Automatic tunnelling and IPv4 compatible address in RFC1933 to be deprecated.

good question. anyone aware of an IETF document, giving a detailed description of why we deprecated automatic tunnels?
the best I can come up with, regarding IPv4 routes in IPv6 is:
http://www.windows-ipv6.org/index.php?page=implementation&selectlanguage=eng

> - Should we take it, then, that you reject moving from DS routing to IPV6-only routing without address/prefix changes as a use case you are interested in?

*talking about the general case here*
IPv4 addresses are used to number the outside of a CPE NAT, and can have relatively short address leases today. the resulting renumbering event only affects ongoing TCP sessions.

given that, it doesn't sound like the main use case for MAP.
it can be implemented in MAP, with a single rule as well; e.g. by assigning a separate IPv6 prefix /128 prefix to each CE.

what are we arguing over? if 4rd-U is better than MAP? in the MAP effort we chose to drop quite a number of suggested features, because we didn't think the added complexity/confusion was worth it. the working group are free to add any feature from the feature buffet.

cheers,
Ole

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 7 Feb 2012 15:26:41 +0100

> Ingress filtering of the domain has checked that the IPv6 source starts with the delegated IPv6 prefix, a /112 which includes the IPv4 address. In the 4rd-E case, the BR checks that the source addr…

It looks like that you treat default mapping rule as a basic mapping rule to check source address consistency on the BR. It should work, and the MAP too.

> I am ready, however, to look seriously at individual cases where choices were different.

Basically provision MAP CE is based on its delegated IPv6 prefix in concept. It is opposed to your case but technically possible. Now I concern that it requires much complicated CE implementation. 

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Feb 2012 16:10:39 +0100

Le 2012-02-07 à 15:26, Satoru Matsushima a écrit :

> It looks like that you treat default mapping rule as a basic mapping rule to check source address consistency on the BR. It should work,

Yes, thanks.

> and the MAP too.

I don't see that.
The bit that, in 4rd-U hub&spoke, is changed for the CE-to-BR direction has been included precisely to support this case. 
Otherwise, packets sent by a CE to another CE would be routed directly to its destination, without a detour via a BR. 

> Basically provision MAP CE is based on its delegated IPv6 prefix in concept. It is opposed to your case but technically possible.

> Now I concern that it requires much complicated CE implementation.

All what is required is that CEs set an address bit if hub&spoke topology is required.

Cheers,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 7 Feb 2012 16:24:12 +0100

> Otherwise, packets sent by a CE to another CE would be routed directly to its destination, without a detour via a BR. 

I don't think so. I just mention BR behavior here.
You mention CE behavior for whether the bit is set or not.

> All what is required is that CEs set an address bit if hub&spoke topology is required.

So how CE decide to set the bit, and when the CE figure it out?
--satoru

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Feb 2012 16:46:38 +0100

> I don't think so. I just mention BR behavior here.

Yes, but AFAIK the solution needs to involve CEs

> You mention CE behavior for whether the bit is set or not.

Yes, please see below.

> So how CE decide to set the bit, and when the CE figure it out?

The CE knows it must set this bit if, and only if, it received at initialization a Topology-variant parameter set to Hub&spoke (sec 4.1).
In this case, the CE sets bit 79 to 1 in IPv6 destination addresses of all packets it sends.

BTW, this bit should better, for clarity, be given a name, e.g. bit B meaning To-BR bit (or whatever better idea one could propose). I plan to do it in the next version.
  
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 7 Feb 2012 17:35:25 +0100

On 2012/02/07, at 16:46, Rémi Després wrote:

--snip--

> BTW, this bit should better, for clarity, be given a name, e.g. bit B meaning To-BR bit (or whatever better idea one could propose). I plan to do it in the next version.

So you mean that if the hub&spoke bit is set, a CE derives /112 IPv6 prefix as 4rd end point from IPv4 address which is already assigned. Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. right?

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Feb 2012 17:53:31 +0100

Le 2012-02-07 à 17:35, Satoru Matsushima a écrit :

> So you mean that if the hub&spoke bit is set, a CE derives /112 IPv6 prefix as 4rd end point from IPv4 address which is already assigned.

If the CE is delegated a prefix shorter than /64, it isn't concerned with the To-BR bit.
If it is delegated a /112, it finds its IPv4 address inom it. 
It then must set the To-BR bit, in its outgoing IpV6 destinations, iff the Topology variant is Hub&spoke.  

> Otherwise, a CE derives its IPv4 address from delegated IPv6 prefix. right?

The CE always derives its 4rd prefix from its delegated IPv6 prefix, based on the Mapping rule that has the longest match.

RD

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 7 Feb 2012 11:43:04 -0600

I would shy away from drawing that conclusion, given the implementation specifics.

Cheers,
Rajiv

> -----Original Message-----
> From: Rémi Després [mailto:[email-masked]]
> Sent: Tuesday, February 07, 2012 8:28 AM
> To: Rajiv Asati (rajiva)
> Cc: Satoru Matsushima; Softwires WG; Wojciech Dec (wdec)
> Subject: Re: [Softwires] MAP&4rd-U - DS routing replaced by v6-only routingin
> hub&spoke topology
> 
> 
> 		the 4rd-E case, the BR checks that the source address in the
> IPv4 header matches that of the IPv6 address.
> 
> 
> Consistency check between source IPv4 address and source IPv6 address is
> always part of encapsulation solutions (translation or header-mapping solutions
> are not concerned).
> 				In a use case described in the 4rd-U draft (sec
> 5.3), an ISP replaces its dual-stack routing by IPv6-only routing.
> 
> 
> 				For this, independently from the number of
> IPv4 prefixes it has to support, it uses only one mapping rule.
> 
> 
> 				(By replacing each IPv4 route by an equivalent
> IPv6 route, it ensures that all customers keep their IPv4 addresses.)
> 
> 
> 
> 
> 
> 
> 
> 
> 			I don't think that it could work as you explained in that
> section. For example, the BR would need to check a received packet from a CE
> whether it has correct source address in mapping rule or not. It means that the
> BR must know all address mappings for CE between IPv4 addresses and IPv6
> prefixes. Is it correct understanding?
> 
> 
> 
> 		Ingress filtering of the domain has checked that the IPv6 source
> starts with the delegated IPv6 prefix, a /112 which includes the IPv4 address. In
> the 4rd-E case, the BR checks that the source address in the IPv4 header
> matches that of the IPv6 address. There is therefore no need for the BR to know
> all IPv4 prefixes. At its IPv4 interface, all received packets start with one of
> them. At its IPv6 interface, all packets it receives have an embedded address
> that starts with one of these prefixes.
> 
> 
> 
> 			I think that operators who already deploy such dual-
> stack network is supposed that they have address mapping table,
> 
> 
> 
> 		I would rather suppose that ISPs that have added IPv6-prefix
> delegation, say /56s, to an existing IPv4 network did it without mixing their IPv6
> plan with their IPv4 prefixes.
> 			they can provision each CE individually, and also they
> are capable to distribute the default mapping rule since they should install it
> into the CEs. In that situation, what's the motivation of why the operator want
> to provision with only default mapping rule?
> 
> 
> 
> 
> 
> 			cheers,
> 
> 
> 			--satoru
> 
> 
> 
> 
> 
> 				For this to work, the 4rd-U draft has a bit that,
> in the hub&spoke case, differs between CE-to-BR and BR-to-CE directions. Thus,
> packets sent to a CE take different routes depending on whether sent by a CE or
> a BR.
> 
> 
> 
> 
>

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 08 Feb 2012 12:52:50 +0100

Hello Remi,

On 07/02/2012 11:13, "Rémi Després" <[email-masked]> wrote:

> For this to work, the 4rd-U draft has a bit that, in the hub&spoke case,
> differs between CE-to-BR and BR-to-CE directions. Thus, packets sent to a CE
> take different routes depending on whether sent by a CE or a BR.

Would this be the "bit set in the V byte"?

With MAP-T, the BR prefix(es) and the CE prefix(es) can be different.
Matching on the source and destination prefix combination allows CE-CE
traffic in a MAP domain, if one cares to detect such traffic.
As you may recall classification of "MAP" and "non-MAP" traffic, is a topic
we discussed in Beijing and in the design team, and there appeared to be
little practical need for it from operators. Nothing in MAP precludes from
adding that, if the need would actually be more substantial.

Regards,
Woj

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 8 Feb 2012 13:43:32 +0100

> It then must set the To-BR bit, in its outgoing IpV6 destinations, iff the Topology variant is Hub&spoke.  

As you described in your draft, if a CE is delegated /112 IPv6 prefix, the CE automatically form itself for H&S mode and extract a non-sharing IPv4 address from the /112 prefix.

> The CE always derives its 4rd prefix from its delegated IPv6 prefix, based on the Mapping rule that has the longest match.

So you mean that it is only specific case of which if the extracted IPv4 address is same with an address assigned to a dual-stack interface on the CE, the default route on the CE is forced to the BR, and keep that address on the dual-stack interface as NAPT source address. Is that what you request to 4rd-U CE implementation?

It also requires operator to manage specific /112 route for each CE that means IPv4 host routes are injected to the operator's IPv6 routing table that's what Ole already pointed out. I agree with Ole that I'm doubt it could be widely acceptable technique for operators.

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Feb 2012 19:20:35 +0100

> Would this be the "bit set in the V byte"?

No.
As you know, the V octet is the first one in Interface IDs.
The ToBR bit is in the lower bit of the next octet, bit 79 as shown on figures.
Where it is said to be 71, it is  is a typo. Sorry for that.  

> little practical need for it from operators.

Full freedom of subnet prefixes in CE sites in all cases wasn't really understood yet, AFAIK.

> Nothing in MAP precludes from
> adding that,

Agreed

> if the need would actually be more substantial.

The need is hub&spoke combined with full IPv4 addresses embedded in IPv6 addresses.
If forbidden, it should be documented.

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Feb 2012 19:33:38 +0100

> As you described in your draft, if a CE is delegated /112 IPv6 prefix, the CE automatically form itself for H&S mode and extract a non-sharing IPv4 address from the /112 prefix.

Hub&spoke vs Mesh is independent from /112.
Otherwise, yes, a CE always derives its IPv4 address when it receives a /112 matching the default mapping rule.

> So you mean that it is only specific case of which if the extracted IPv4 address is same with an address assigned to a dual-stack interface on the CE, the default route on the CE is forced to the BR,

Yes, by setting the ToBR bit.

> and keep that address on the dual-stack interface as NAPT source address. Is that what you request to 4rd-U CE implementation?

I think so.

> It also requires operator to manage specific /112 route for each CE that means IPv4 host routes are injected to the operator's IPv6 routing table that's what Ole already pointed out.

Well, an ISP has assigned that has assigned fixed IPv4 addresses, and wants to keep them while moving to IPv6-only routing needs, one way or another, to reflect IPv4 routes in IPv6. 

> I agree with Ole that I'm doubt it could be widely acceptable technique for operators.

It is useful for ISPs that have this use case, even if there aren't many, and in any case creates no harm for others.
It is a way to encourage IPv6 routing for ISPs that don't want to maintain DS routing.

RD