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

["Rajiv Asati (rajiva)" <[e-mail]>]

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

Cheers,
Rajiv

> -----Original Message-----
> From: Rémi Després [mailto:[e-mail]]
> 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
> 
> 
> Le 2012-02-07 à 14:18, Rajiv Asati (rajiva) a écrit :
> 
> 
> 		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?
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 	Cheers,
> 	Rajiv
> 
> 	Sent from my Phone
> 
> 	On Feb 7, 2012, at 8:03 AM, Rémi Després
> <[e-mail]> wrote:
> 
> 
> 
> 
> 
> 		Le 2012-02-07 à 13:07, Satoru Matsushima a écrit :
> 
> 
> 
> 			Hi Remi-san,
> 
> 
> 
> 
> 
> 			On 2012/02/07, at 11:13, Rémi Després wrote:
> 
> 
> 
> 
> 
> 				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.)
> 
> 
> 
> 
> 
> 
> 
> 
> 			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.
> 		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
> 
> 
> 
> 
> 
> 				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
> 
> 
> 
> 
> 
> 
> 	_______________________________________________
> 
> 
> 				Softwires mailing list
> 
> 
> 				[e-mail]
> 
> 
> 
> 	https://www.ietf.org/mailman/listinfo/softwires
> 
> 
> 
> 
> 
> 
> 		_______________________________________________
> 		Softwires mailing list
> 		[e-mail]
> 		https://www.ietf.org/mailman/listinfo/softwires
> 
>