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

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

> ability instead of the more general five-tuple based IPv4
> classification ability should be reserved, when deliver IPv4 over
> IPv6?

How would one get 5-tuple based classification when delivering IPv4 "over" IPv6, if the v4 packet is not translated into v6?

The fact of the matter is that "5-tuple" could be a luxury that may not always be available.

Cheers,
Rajiv


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of xiaohong deng
> Sent: Tuesday, October 04, 2011 3:26 AM
> To: Wojciech Dec (wdec); [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Softwires] 4rd Address Mapping - version-01
> 
> Hi Remi, Ole, Woj, and all,
> 
> I understand the argument of IID bits is resulted from a last minute
> agreement between 4rd and divi-pd people that having full IPv4 address
> embedded in the address format helps source based classification, but
> before we argue that, shall we first make this agreement also be
> accepted by community wide? As far as current time-being concerned, I
> don't see a consensus has been reached on this agreement from
> community wide.
> 
> It IMHO would be helpful if anybody would clarify some details to 1)
> first prove source based classification is either a valid or a
> non-valid requirement for address mapping; For this regard, I would
> begin with that why do we think the source based IPv4 classification
> ability instead of the more general five-tuple based IPv4
> classification ability should be reserved, when deliver IPv4 over
> IPv6?
> 
> 
> and 2) then show us how much other efforts are required to achieve so
> besides address format definition itself, in other words, if it's a
> valid requirement, let's first have feasibility of this requirement
> analyzed from both deployment and operational perspectives:
> 
> 1. For double translation, how does a traditional router perform the
> source based IPv4 packet classification on IPv6 (translated from IPv4)
> packets? Or does it suggest that using IPv6 classification filters to
> filter IPv4 packets? If so, should we also note that this suggests
> IPv4 operation and managed are tightly coupled with IPv6 operation and
> management? which in turn implies complexity in operational, or put in
> other words, OPEX increasing, the last thing among others that
> operators would like to see.
> 
> 2. For encapsulation, even if embedding source IPv4 addresses in the
> lower bits of the address formats, where does the router find the
> source port without de-capsulation? Are you suggesting also encode 16
> bits port in the lower part of address? In either case, it leads to
> the concerns of increased OPEX to operators stated above.
> 
> Thoughts?
> 
> Cheers,
> Xiaohong
> 
> > Hi Qiong,
> >
> > Some fields of a unified address format for double translation and
> > encapsulation might be unnecessary for hub and spoke, but using the
> > same format should be advantageous for maintenance and training if for
> > nothing else (assuming that any added complexity is negligible
> > enough).
> >
> > Believing that a completely unified format is possible, I mentioned it to
> Alain.
> > Also, I volunteered to be editor-coordinator for this to happen, but
> > decision of who does what is his.
> >
> > Regards,
> > RD
> >
> >
> > Le 4 oct. 2011 à 00:13, Qiong a écrit :
> >
> >> Hi Remi and Wojciech,
> >>
> >> Thanks for your clarification. I fully agree with you that embedding the
> full IPv4 address in the last 64 bits would be quite helpful for some kind of
> source address classification and I also suggest that this can be taken in the
> same way for encapsulation-based approach. It would be easier for systems in-
> the-middle to identify the IPv4 address without packet decapsulation.
> >>
> >> I guess the thing that Ole has mentioned to "look at 24 bits in the middle
> of IPv6 address" is for CE to determine whether a downstream IPv6 packet
> should be taken for translation or native forwarding. Here, for a dual-stack
> host, there would be no difference in the first /64 bits for a native IPv6
> packet and a translated packet. What's why the CE should further looking into
> the last 64 bits to determine the translation process or native forwarding.
> Maybe Ole can clarify for this part again.
> >>
> >> However, the situation would still be different in "Hub & Spoke" and "Mesh"
> mode. For Hub & Spoke case, since BR will have a default prefix/address, it
> would be easily to identify the translated traffic from native IPv6 traffic by
> just doing source address routing lookup for a downstream packet. So, the
> corresponding mechanics would be different.
> >>
> >> Thanks
> >>
> >> Best wishes
> >>
> >> Qiong
> >>
> >> 2011/10/3 Wojciech Dec <wdec at cisco.com>
> >>
> >>
> >>
> >>
> >>     On 02/10/2011 02:58, "Qiong" <bingxuere at gmail.com> wrote:
> >>
> >>         Hi Ole and Remi,
> >>
> >>             > This is my answer to your first (double) question.
> >>             > 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.
> >>
> >>             Woj> What are you referring to? Routing "just works" as normal
> and is non disaggregated because of the CE-index in the prefix. Classification
> can/is done on a subset of the v6 address, and that is perfectly legit.
> >>
> >>
> >>             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?
> >>
> >>
> >>         Qiong : I agree that routing lookup for a provisioned /64 prefix
> would be better that extracting certain bits for each IPv6 address in CE. This
> would bring less change to existing routing model.
> >>
> >>         Woj> There is no change to the existing destination based routing
> model. Each CE is uniquely addressed by the CE bits in the top /64 - ie the CE
> index is as proposed by all the 4rd and divi-pd drafts. The full v4 source
> address of each CE is however also embedded in the interface-id, as per
> RFC6052. There appears to be no cost for this operation, and has the upside of
> the full v4 info visible in the header and allowing source based
> classification (should one want to do that).
> >>
> >>         Regards,
> >>         Woj.
> >>
> >>         Best wishes
> >>
> >>         Qiong
> >>
> >>             _______________________________________________
> >>             Softwires mailing list
> >>             Softwires at ietf.org
> >>             https://www.ietf.org/mailman/listinfo/softwires
> >>
> >>
> >>
> >
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires