Re: [Idr] Fw: Re: New Version Notification for draft-xie-idr-mpbgp-extention-4map6-00.txt

[Robert Raszuk <[e-mail]>]

Hi Xiejingrong,

The PE2, as the “egress side”, get an IPv6 packet that is NOT encapsulated,
> but translated from an IPv4 packet, it won’t be expected to “decapsulate
> again you do a lookup on plain IPv4 FIB” as you described ----because
> there is no encapsulated IPv4 header at all !
>

The end sites talk IPv4 only. Is this correct ? If so they send and receive
IPv4 packets - correct ?

So the simplest way to deliver the service is to encapsulate this packet in
the IPv6 header.

If however, as you say, remove IPv4 header and *replace it* with IPv6
header containing MAP address that is a form of 46NAT. The exact
reverse operation must be done on egress 64NAT. Besides there are other
fields in IPv4 header which needs to be transparently translated and
carried through. That is lot's of mapping and complexity - just consider
ToS bits, TTL transparency, checksum, Flags etc ... The src and dst are
your least worry here.

Now let’s see PE1, as the “ingress site”, may get an packet destined to
> Host2 but may from Host1/3/5 (with source address being
> 192.168.1.x/192.168.3.x/192.168.5.x respectively), it can “do the dst
> lookup on IPv4 address” but it can’t “result in IPv6 encapsulation with
> src and dst address”!
>

Why not ? I do not see an issue. The lookup reveals the rewrite (complete
or incomplete). The input from src packet can be used to create a new
header with mapped v4tov6 both src and dst addresses.


> When the source address is 192.168.1.x, then PE1 should do an src lookup
> and result a 4map6 address-block (or prefix) like 2001:db8:1:1:1:1:192.168.
> 1.x/120;
>
> When the source address is 192.168.3.x, then PE1 should do an src lookup
> and result a 4map6 address-block (or prefix) like 2001:db8:1:1:1:1:192.168.
> 2.x/120;
>
> When the source address is 192.168.5.x, then PE1 should do an src lookup
> and result a 4map6 address-block (or prefix) like 2001:db8:1:1:1:1:192.168.
> 3.x/120;
>
> Only in this way, PE2 can to a “reverse translation” or
> “6map4-Translation” on an IPv6 packet, from IPv6 dst/src address to IPv4
> dst/src address.
>

That would be clearly possible in what I am proposing.

Kind regards,
Robert





>  I think the overall 4map6 solution, including 4map6-Translation, and
> 4map6-Encapsulation, is different than the “legacy Encapsulation” that is
> normally thought about (like SRv6 VPN defined in RFC9252).
>
>
>
> From your point (1)/(2)/(3), it seems that you take 4map6 the same as
> “legacy Encapsulation” ?
>
>
>
> Kind Regards,
>
> Jingrong
>
>
>
>
> 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments may contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
>
>
>
> *From:* Robert Raszuk [mailto:[e-mail]]
> *Sent:* Saturday, January 28, 2023 10:23 PM
> *To:* Xiejingrong (Jingrong) <[e-mail]>
> *Cc:* Chongfeng Xie <[e-mail]>; [e-mail]; idr <
> [e-mail]>; xing <[e-mail]>
> *Subject:* Re: [Idr] Fw: Re: New Version Notification for
> draft-xie-idr-mpbgp-extention-4map6-00.txt
>
>
>
> Hi,
>
>
>
> The crux is that to realize connectivity of IPv4 sites over only IPv6 core
> (or set of domains) all you need to get is the remote encapsulation
> information carried in Tunnel Attribute. That should be already supported
> and shipping by multiple implementations.
>
>
>
> Then to meet BGP requirements you need a valid next hop hence you need to
> use extensions described in RFC5549 to add it to SAFI 1/1. RFC8950 is not
> actually playing any role here as it clearly says that it augments only the
> scenario for SAFI 128/129 respectively.
>
>
>
> So the fundamental point is that you do not need to create and carry
> IPv4mappedIPv6 address at all. It is not needed for network elements as
> their FIBs will still only use vanilla IPv6 and IPv4 addresses separately.
> Even if you extend protocol and carry IPv4 mapped IPv6 address the ingress
> FIB from IPv4 site will still do the dst lookup on IPv4 address.
>
>
>
> That lookup will result in IPv6 encapsulation with src and dst address
> being locally computed (algorithm is well know as we already established
> before).
>
>
>
> Then IPv6 packet will happily travel via single or many domains.
>
>
>
> On the egress side once you decapsulate again you do a lookup on plain
> IPv4 FIB to determine which site the packet should be forwarded to.
>
>
>
> So in no moment of the packet life through this single or multi domain
> journey you need to have to propagate IPv4mappedIPv6 address anywhere.
>
>
>
> I hope this clarify the point I was making all along this little thread.
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Jan 28, 2023 at 1:07 PM Xiejingrong (Jingrong) <
> [e-mail]> wrote:
>
> Hi Robert,
>
>
>
> I think it is a valid option to use existing SAFI such as those
> (SAFI-1/128) described in RFC5549/8950.
>
>
>
> But I don’t understand this sentence “It does not even require any new
> software upgrade to existing routers if they
> already support RFC5549+RFC9012.”
>
>
>
> My understanding of the overall 4map6 solution is in my previous mail [*],
> and I think the main requirement for the BGP extension in the solution is
> an “IPv4/IPv6 Prefix” information in an TLV/Sub-TLV/Sub-sub-TLV of some BGP
> Attribute.
>
>
>
> [*] https://mailarchive.ietf.org/arch/msg/idr/fUMnsJpSwoU3Vz-3NrcUCQqggfY/
>
>
>
> But I failed to find a TLV or Sub-TLV that can carry an IPv4/IPv6 Prefix
> after reading RFC9012 quickly.
>
>
>
> Can you please clarify on that ?
>
>
>
> Regards,
>
> Jingrong
>
>
>
>
> 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments may contain confidential information from
> HUAWEI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
>
>
>
> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, January 28, 2023 6:55 PM
> *To:* Chongfeng Xie <[e-mail]>
> *Cc:* [e-mail]; idr <[e-mail]>; xing <[e-mail]>
> *Subject:* Re: [Idr] Fw: Re: New Version Notification for
> draft-xie-idr-mpbgp-extention-4map6-00.txt
>
>
>
> Chongfeng,
>
>
>
> 【*Chongfeng*】: I agree with you, introducing IPv4 routes into IPv6 domain
> will increase the size of control plane, but I think this is normal, you
> have mentioned RFC5549/8950 several times, RFC5549/8950  also adopts new
> SAFI value
>
>
>
> I do not recall ever mentioning RFC8950, but it DOES NOT introduce new
> SAFI. Please read section 3 of either RFC5549 or RFC8950.
>
>
>
> I mentioned RFC5549 with RFC9012 which requires new capability not a
> new SAFI- that's all. It does not even require any new software upgrade to
> existing routers if they already support RFC5549+RFC9012.
>
>
>
> All that is needed is just a few lines of configuration - that's all.
>
>
>
> Regards,
>
> R.
>
>
>
>
>
>
>
> , and specifies the extensions necessary to allow the advertising of IPv4
> NLRI with a next-hop IPv6 address, herein 128-bits of next IPv6 address
> will be used for all IPv4 routes. My proposal is basically the same as
> RFC5549/8950 in terms of the scale, the difference is that my draft use
> IPv6 mapping prefix instead of specific next-hop IPv6 address.  In
> addition, my draft is about IPv6-only deployment for the network. IPv6-only
> will run after dual-stack as a whole. At that time, IPv6 will be the main
> stream, and the use of IPv4 will be less, and the overall quantity of IPv4
> routes may be reduced hopefully.
>
>
>
> Furthermore, the forwarding of IPv4 services in P routers will be based on IPv6 FIB, the size of which is
>
> In all cases forwarding in P routers will be based on IPv6 FIB so I do not
> understand why you are highlighting it here.
>
> *[Chongfeng]:  * You mentioned the cost issue before, and IPv6-only in
> multi-domain networks can reduce the cost of data forwarding, so I
> highlighted it.  BTW, What does "in all cases" here mean?
>
>
>
>
>
> Your statement sounded like what I am describing would not be forwarded
> based on IPv6 FIB so I commented on it.
>
> 【Chongfeng】：OK
>
>
>
> *[Chongfeng]: * In large-scale networks, it is not enough to achieve
> IPv4/IPv6 packet conversion only through local algorithmic computing. To
> convert an IPv4 address to an IPv6 address in PE, it needs to obtain the
> IPv6 address prefix of remote-end to identify the location of the IPv4
> address block in the IPv6 network in advance.
>
> In addition, I think the/96 prefix you mentioned is about the choice of
> prefix length, which can be considered in the future.
>
>
>
>
>
> I disagree. Irrespective of network scale you can algorithmically and
> consistently insert a bit string into a packet.
>
>
>
> And the algorithm we are talking about it well know so there is no issue
> what so ever.
>
> 【*Chongfeng*】： Can you tell me which RFC the algorithm is in?
> MAP-T/MAP-E?  or something else?
>
>
>
> I am not talking about some local domain mapping.
>
>
>
> Thx,
>
> R.
>
>
>
> Thanks!
>
> Chongfeng
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>