Re: [Rift] Fw:Re: Re: Ipv4 and ipv6 cooperating in rift

Antoni Przygienda <> Fri, 12 July 2019 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48DBC1200E7 for <>; Fri, 12 Jul 2019 07:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3XBcvvG2Hoi3 for <>; Fri, 12 Jul 2019 07:02:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1F091200CD for <>; Fri, 12 Jul 2019 07:02:40 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x6CDxDSf027857; Fri, 12 Jul 2019 07:02:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=13EyqMV7LOzDckcKMIWmKEwla2Hrj8bRbkj6mq8h8tE=; b=2Xvw/4djhyQPrKoHIiiW5o7DooJbY5kEu512ossLpiaq7DHv+YenWEa0qliPIZ9KtyJR N/caqIouaMlfmwQ/CmsrLahO1iYZ1iCfQOjLdJcfirFL3Mnv4aCJz6vzXr0F77zvM++T XulMizeaXPcZDwjr7VMrqz24aSUxxD62RldOVGzj/WabXEsCfq5yc5ecx3/K+nXIEm2q 7CL8WeiUReOBFR+UAuypaD305nl6D7oN200PKvCcbJD5dRrs8irsc/f/rweq+ovE3izE IX3D0QHwg9aXp1F/lykxhYoVI+r7D5bkf1bzmphxP3cvmQu28URxgOrEl4qOTEuudvDs xQ==
Received: from ( []) by with ESMTP id 2tpswer5p8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 07:02:38 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Jt3qac99x4LURlEL6cqMKjNUWpSDL53ggiGZwvsbYOtQ7VFtfDDJSzl5avE61OfShZqmP2c4SfPsap5ZxLYcAy4WpOroNMC2KE8DME0ny2nogmWUf7lpaXyfTpK9pyEMWP2NDBSaP0a3X+JrsZLnHOE036DCDGb0OSBg6T+sKVi9dsjIe76MGcrGtb4f1tuP6p1X0IXI0eVuFL3odyTVIw1Py04aUOWv/jlhC2xc7wogysm6g8kX0CYuklhUSWbTPim700qst+tyuDLSa0VFq2ev9NmqIbs6Hnoa/CCiufFtn7SSHr9P9WiVVU5TKpM0dQH+yRXDvLi94NIUgRaH7g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=13EyqMV7LOzDckcKMIWmKEwla2Hrj8bRbkj6mq8h8tE=; b=iOAPZYAwHEWzBOz5flBlmcw9H/JsmXksTvSUnhjfOElK16rUbU3/9lSFGJjPdP0u3VEA4vqn46IqoVzbeH6aXxVaClTDLaBDoGLNIrFe7BBfe6basD8GdqLpXvCPiZFOxrbH65fFJOpGFYYddGE+3F39FaGXu7CtYk/BMfEDvb+g5U8l+Loqt8iPDsfLwt5txrm/MRtJ5wbyXVqiEqKJwEaVEnPlqZJDqU7vSp1ap27x5cylH9EQMmvT401MCDZTY36qlX1Xkl4eNNu8Yf7TGeJAFtFLFW+082aeCBWl0XVZLd9itBOHl4NAA6ZWnDIkIwukUrXcZA1HdvMY5kyLRQ==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.6; Fri, 12 Jul 2019 14:02:30 +0000
Received: from ([fe80::37:4711:1630:3ff0]) by ([fe80::37:4711:1630:3ff0%10]) with mapi id 15.20.2073.008; Fri, 12 Jul 2019 14:02:30 +0000
From: Antoni Przygienda <>
To: "" <>
CC: "" <>, "" <>
Thread-Topic: Re:Fw:Re: Re:[Rift] Ipv4 and ipv6 cooperating in rift
Thread-Index: AQHVN8vGZbTZZ+0IyE+CmuEc6N8hfqbFkibdgAE1DgCAADxeqg==
Date: Fri, 12 Jul 2019 14:02:30 +0000
Message-ID: <>
References:,, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 895ed6cd-99c3-4763-dfa9-08d706d19475
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MWHPR05MB3439;
x-ms-traffictypediagnostic: MWHPR05MB3439:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-forefront-prvs: 00963989E5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(346002)(396003)(366004)(136003)(376002)(189003)(199004)(478600001)(71190400001)(71200400001)(4326008)(7696005)(76176011)(53546011)(2501003)(229853002)(30864003)(2906002)(102836004)(14454004)(6116002)(2351001)(6916009)(186003)(52536014)(66066001)(3846002)(26005)(8676002)(486006)(7736002)(74316002)(11346002)(99286004)(25786009)(5640700003)(5660300002)(6246003)(76116006)(53936002)(19627405001)(6436002)(53946003)(68736007)(66446008)(33656002)(6506007)(5024004)(14444005)(256004)(476003)(81166006)(81156014)(66946007)(8936002)(54906003)(54896002)(9686003)(86362001)(105004)(446003)(316002)(64756008)(66556008)(66476007)(55016002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3439;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: c7dT7vHSqjvP/IWzPb1vX6PLwOAtoOkzghPV9UrpNO5WW+KO9pQrPP+x1zO072ZENNNhUTGHzfe8twHcxp23BVsFGITcmtfN3lv7rzD4F+5djJZwTgHsVo7LITh6GkZMrxfZv6LTFO3yuxPixhdqZrnEozb9K0HCohUwpA4TWHhDxXebM9ckrtL4d/niJ/sCNsuX7iVN2CQ/7h3WMjGXv50e+7BmnVwXp6XRt2/xdyZRaOZlNIUotdHIkBrGCZ+32LqobUkH5irKOl10pu67s0Qp1PQ8AYmXHWQZlQRNl0VgbSfNBA2lqnomGdyKVBWamN9Wx6YXx/DU0BGKLORsHc4Fh/ci9ZPx75vt5c8Cn8ctmHSXZpUFXdmsGrbFfnYxUVQlqVPkKx5IHLyKfpN/s3mtihNB1PzIeKBYD7N28NU=
Content-Type: multipart/alternative; boundary="_000_MWHPR05MB3279A23783994C80FE41F577ACF20MWHPR05MB3279namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 895ed6cd-99c3-4763-dfa9-08d706d19475
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 14:02:30.3749 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3439
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-12_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907120152
Archived-At: <>
Subject: Re: [Rift] Fw:Re: Re: Ipv4 and ipv6 cooperating in rift
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2019 14:02:45 -0000

Benchong, ok, we're in sync then.

It seemed obvious to us that sending a v4 LIE will include a v4 source address and v6 equivalently a v6 source address (there is no other way) and obviously those are the directly connected so I omitted all that in the spec.

So spec says IMO enough as it is about the LIE issues including talking about same link locals on multiple links


An implementation MAY listen and send LIEs on IPv4 and/or
IPv6 multicast addresses.  LIEs on same link are considered
part of the same negotiation independent on the address family
they arrive on. Observe further
that the LIE source address may not identify
the peer uniquely in unnumbered or link-local address cases so
the response transmission MUST occur over the same interface the LIEs have been
received on. A node CAN use any of the adjacency's source addresses it
saw in
LIEs on the specific interface during adjacency formation to send TIEs.
That implies that an implementation MUST be ready to accept TIEs on
all addresses it used as source of LIE frames.


Yes, dynamic withdrawal of AFs is a rathole I would encourage e'one to stay away from. If AF goes away, we reset the adjacency.

--- tony
From: <>
Sent: Friday, July 12, 2019 3:20 AM
To: Antoni Przygienda
Subject: Re:Fw:Re: Re:[Rift] Ipv4 and ipv6 cooperating in rift


I get the rule now, thank you!

It should send multi lies in same interface with different source address include v4 and v6 which we want to use the address as a gateway. It confused me in the previous discussion and I did't find it in the protocol. It is different with other protocols. Bruno's code has already implemented.

In this case, the 3-way state switching forword the rule in 5.2.2


Observe further that the protocol does NOT support selective

   disabling of address families or any local address changes in three

   way state, i.e. if a link has entered three way IPv4 and/or IPv6 with

   a neighbor on an adjacency and it wants to stop supporting one of the

   families or change any of its local addresses, it has to tear down

   and rebuild the adjacency.  It also has to remove any information it

   stored about adjacency's' LIE source addresses seen.


Then the nexthop selection of the rib table depends on the device itself and I support this.

thank you!


发件人:AntoniPrzygienda <>
收件人:徐本崇10065053; <>; <>rg>;
日 期 :2019年07月12日 00:38
主 题 :Re: Fw:Re: Re:[Rift] Ipv4 and ipv6 cooperating in rift
Benchong, as to your last intersting question:


Is it possible to generate a valid v6 rib table as long as v4 address of the inteface is valid? Can it support ipv4 and ipv6 double stack?


answer is "yes, but practically if your interface can fwd' IPv6 frames it also runs ND so you will have a v6 link local which seems much more natural as next-hop rather than maltreat v4 addresses to build v6 next-hops from ;-) Unless you have some funky silicon  limitations where such a thing is a good thing ;-)

So, you see why the spec is written to the point it's written and silent on specification how to precisely build next-hops/gateways. It can be implemented in couple different ways which are very close to implementation techniques/HW used so trying to nail that  in protocol spec would be over-specification which is almost as bad as under-specification ...

--- tony
From: <>
Sent: Thursday, July 11, 2019 2:33 AM
Cc: Antoni Przygienda
Subject: Fw:Re: Re:[Rift] Ipv4 and ipv6 cooperating in rift

Hi, Bruno

I read part of your RIFT code, thank you for your great job!

When sending LIE messages, as long as there is a v4 address, v4 will be used first, so we will get v4 next hop.


    def action_start_flooding(self):


       # For sending flooding packets, use whatever IPv4 or IPv6 address we see first for the

        # neighbor, preferring the IPv4 address if we know both.

        if self.neighbor.ipv4_address is not None:

            self.rx_info("Start IPv4 flooding: send to address %s port %d",

                         self.neighbor.ipv4_address, tx_flood_port)

            self._flood_tx_ipv4_socket = self.create_socket_ipv4_tx_ucast(




            assert self.neighbor.ipv6_address is not None

            scoped_ipv6_address = self.neighbor.ipv6_address

            if "%" not in self.neighbor.ipv6_address:

                scoped_ipv6_address += "%" + self.physical_interface_name

            self.rx_info("Start IPv6 flooding: send to address %s port %d",

                         scoped_ipv6_address, tx_flood_port)

            self._flood_tx_ipv6_socket = self.create_socket_ipv6_tx_ucast(



SPF calculation will calculate the nexthop of v4 and v6 at the same time.


    def set_spf_predecessor(self, destination, nbr_tie_element, predecessor_system_id,



        if (nbr_tie_element is not None) and (predecessor_system_id == self.system_id):

            for link_id_pair in nbr_tie_element.link_ids:

                nhop = self.interface_id_to_ipv4_next_hop(link_id_pair.local_id)

                if nhop:


                nhop = self.interface_id_to_ipv6_next_hop(link_id_pair.local_id)

                if nhop:



            dest_table = self._spf_destinations[spf_direction]


The RIB table only selects the same AF nexthop


    def spf_install_routes_in_rib(self, spf_direction):


                prefix = dest_key

                if prefix.ipv4prefix is not None:

                    next_hops = dest.ipv4_next_hops

                    route_table = self._ipv4_rib


                    assert prefix.ipv6prefix is not None

                    next_hops = dest.ipv6_next_hops

                    route_table = self._ipv6_rib

                if next_hops:

                    rte = route.Route(prefix, owner, next_hops)


Is it possible to generate a valid v6 rib table as long as v4 address of the inteface is valid? Can it support ipv4 and ipv6 double stack?



发件人:AntoniPrzygienda <>
抄送人:Jeffrey (Zhaohui) Zhang <>;张征00007940;  <>rg>;
日 期 :2019年07月11日 11:52
主 题 :Re: Re:[Rift] Ipv4 and ipv6 cooperating in rift
Benchong, what you seem to talk about is originating packets and it's the source that decides whether it sends v4 or v6 and the IP fabric with RIFT just forwards the packet, it cannot change in the middle the IP address family in which the packet is carried   obviously so there is no decision to be made which IP AF is used, only which GW needs to be installed on the route nexthop. But yes, an implementaton can choose to forward v4 packets using the MAC address of a v6 gateway, a highly desirable behavior since   with that, the fabric can be completely global address free without any config (just ND) and do v4 fine.

yes, an implementation may choose to prefer v4 GW for v4 packets and v6 GW for v6 packets but normally it's the same MAC unless the deployment is very strange @ which point knobs to control that may be necessary, something which is implementation specific.

So RIFT just floods the TIEs on any AF with prefixes of all AFs, the computation computes the route with directly attached next-hop which has to resolve to MAC in any AF really and then packet can be forwarded ...

implement it and play with it, we have @ least 2 implementations already that work fine doing that ...

Yes, the closest analogy is v4 in BGP with v6 nexthops if you really want to think that way but RIFT is much simpler since the nhop is always directly connected and we don't talk about anything like v4ov6 or v6ov4 tunneling and so on ...

makes sense?

--- tony

From: <>
Sent: Wednesday, July 10, 2019 8:39 PM
To: Antoni Przygienda
Cc: Jeffrey (Zhaohui) Zhang;;
Subject: Re:[Rift] Ipv4 and ipv6 cooperating in rift

Hi tony

Thanks for your explanation, and I have already understood your opinion on v4v6 forwarding.

The difference between RIFT and other routing protocols is the consistency of packets AF and routes AF. Isis is in L2 encapsulation that solves different address families through multiple topologies. Ospf and rip are strictly distinguished in v4v6. Rift   is actually closer to BGP.

When the interface has both v4 and v6 addresses (or ND enabled), the protocol uses v4 or v6 or v4v6 address encapsulation. It will be better if protocol gave the recommended behavior. Otherwise, different people will give different solutions, which will   cause protocol conformance problem.

The options we can choose are:

a) ND enable v6 first:

If v6 address valid AND ND enable:

     V6 packet

Else if v4 address valid:

     V4 packet

b) v4 first

If v4 address valid:

     V4 packet

Else if v6 address valid(AND ND enable):

     V6 packet

c) coexistence of v4v6

If v4 address valid:

     V4 packet

If v6 address valid(AND ND enable):

     V6 packet

Confused on both the sending and receiving sides.

c) will further have a GW selection problem, preferring to choose the nexthop of the same address family with the prefix, or v4 first.

I'd like the protocol recommends a default behavior and may provides a control method in yang.



发件人:AntoniPrzygienda <>
抄送人:Jeffrey (Zhaohui) Zhang <>;张征00007940;   <>rg>;
日 期 :2019年07月10日 23:12
主 题 :Re: Re:[Rift] Ipv4 and ipv6 cooperating in rift
Hey Benchong, that's an over-interpretation, the spec is looser than that but as far I saw sufficient. Section 5.2.2.

a) Specification does not prohibit RIFT from using _any_ valid IPv6 address on the interface to send IPv6 LIEs. The receiver is supposed to pick up that source address and use it as destination when sending LIEs over v6 and/or TIEs with the receving interface    as gateway. Specification does NOT spell out what happens e.g. on mismatched IP subnets on both sides and so on, situation here is similar to ISIS and different scenarios such as unnumbered links and so on
b) If you want the "laziest" possible implementation then in fact yes, you can fall back on


   All RIFT routers MUST support IPv4 forwarding and MAY support IPv6    forwarding.  A three way adjacency over IPv6 addresses implies    support for IPv4 forwarding.


which makes v4ov6 forwarding inherent part of RIFT. That assumes however that receiving neighbor does support V6 (which the spec does NOT mandate) and nothing will happen if it doesn't. Therefore all RIFT implementation I saw so far send both v4 and v6 which    allows the neighbor to only receive v4 and forward using v4 gateways if it doesn't support V6. In case both v4 and v6 AFs are established, it is up to the implementation which/how it resolves the gateways and there are many interesting advanced issues such    as mixture of spines with v4 and v6 nexthops and how to form ECMP amongst them that the spec does obviously not address since it's all very implementation and silicon specific.

--- tony
From: <>
Sent: Wednesday, July 10, 2019 1:56 AM
To: Antoni Przygienda
Cc: Jeffrey (Zhaohui) Zhang;;
Subject: Re:[Rift] Ipv4 and ipv6 cooperating in rift

Tony, thank you for your reply

Can it be understood that after the ND is enabled, the v6 address needs to be used to build neighbor? In this case, the rift packet of the v4 header is not allowed to be sent and received, and both v4 and v6 routes have a v6 GW.

发件人:AntoniPrzygienda <>
收件人:徐本崇10065053;Jeffrey (Zhaohui)Zhang <>;张征00007940;    <>rg>;
日 期 :2019年07月10日 00:09
主 题 :Re: [Rift] Ipv4 and ipv6 cooperating in rift
Hey Benchong, cc:'ing list, good questions obviously that pop out on implementation

  1.  sending LIE only with v4 will not give you a v6 address to send to (since the LIE source address gives the gateway for the AF, that's why we send LIE per AF) so you won't have a v6 GW address to send TIEs to ;-)

  2.  yes, every interface is independent. Observe that v6 support implies v4 as the spec says (since you can FW v4 without a v4 GW if you have a v6 gateway). However, if one side sends v6 only and the other side only v4 they'll never go 3-way since they won't     be able to receive. We just added a sentence to the spec saying that if you don't send an AF LIE you MUST NOT receive the same AF LIE since we found that loose end in Bruno's implementation when testing security envelopes.  It will be in -07

<t>All RIFT routers MUST support IPv4 forwarding and MAY support IPv6
    forwarding. A three way adjacency over IPv6 addresses implies support
    for IPv4 forwarding. A node that does not process received IPv6 LIEs
    MUST NOT originate IPv6 LIEs.

  1.  IPv6/IPv4 prefix can be mixed in Prefix TIEs. Prefix TIEs do NOT care which interface/AF they are sent over.

  2.  how you build forwarding table and which gateways you use is implemenation dependent but yes, you got the flavor. though your assumption of "Ipv6 destination with ipv4 nexthop" is optimistic. every silicon does v4 so v6 can imply v4, implying v4 fwd'ing     allows v6 forwarding fails on good amount of silicon. But again, those are all implementation knobs, spec only says "v6 implies v4" which means "you better fwd. v4 over v6 nexthops if you see v6 LIEs only"

Observe that node TIEs are _not_ carrying the supported AFs on each interface since I think it would lead to undesirable attempts to deploy (some links can do v6) topologies which defeat the purpose of ZTP/simplicity of RIFT. v6 implies v4, if someone     wants to fwd' v6 over a fabric where certain links are v4 computations get really weird and operationally such a thing is probably a nightmare anyway. And getting v6 working is trivial, just flip on ND and you're in business (at least control plane wise   ;-)

The spec is noit giving implementation advice, it just specifies behavior. In case of doubt looks @ Bruno';s open source. Bruno implemented the whole LIE without ever talking to me and it interop'ed day one without problems.

When you're ready with your implementation to interop, Bruno's code has nice framework you can plug in against open source & Juniper implementation easily

--- tony
From: <>
Sent: Tuesday, July 9, 2019 5:08 AM
To: Antoni Przygienda; Jeffrey (Zhaohui) Zhang;
Subject: [Rift] Ipv4 and ipv6 cooperating in rift


I have some questions about ipv4 and ipv6 cooperating in rift.

Ip head of the rift packet can be V4 or V6, and the prefix in TIE also suport V4 or v6.

Can it support the following situations:

1、A rift interface which send LIE with ipv4 head receiving LIE with IPv6 head;

A rift interface which send LIE with ipv6 head receiving LIE with IPv4 head;

Can they build 3-Way neighbor?

2、Some interfaces in a rift instance send ipv4 head packets, and others in the same instance send ipv6 head packets;

3、Ipv4 head TIE packet fill ipv6 prefix;

   Ipv6 head TIE packet fill ipv4 prefix;(RIFT-06 5.2.2: All RIFT routers MUST support IPv4 forwarding and MAY support IPv6

   forwarding.  A three way adjacency over IPv6 addresses implies

   support for IPv4 forwarding.)

4、In rib table of the rift:

   Ipv4 destination with ipv6 nexthop;

   Ipv6 destination with ipv4 nexthop;

   Ipv4 destination with both ipv4 nexthop and ipv6 nexthop;

   Ipv6 destination with both ipv4 nexthop and ipv6 nexthop;

5、The ip head type(v4 or v6) can be configured in rift interface or instance.

It will be better if there are clear instructions in rift protocol.