%% You should probably cite draft-ietf-l3vpn-mvpn-infra-addrs instead of this I-D.
@techreport{rosen-l3vpn-mvpn-infra-addrs-00,
    number =    {draft-rosen-l3vpn-mvpn-infra-addrs-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-rosen-l3vpn-mvpn-infra-addrs/00/},
    author =    {Rahul Aggarwal and Eric C. Rosen},
    title =     {{IPv4 and IPv6 Infrastructure Addresses in MCAST-VPN Routes}},
    pagetotal = 7,
    year =      2010,
    month =     jun,
    day =       11,
    abstract =  {To provide Multicast VPN service, a provider edge router originates "MCAST-VPN" BGP routes. These routes encode addresses from the customer's address space as well as addresses from the provider's address space. The customer's address space may be either IPv4 or IPv6. Independently, the provider's address space may be either IPv4 or IPv6. The MCAST-VPN BGP routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies whether the provider addresses are IPv4 addresses or whether they are IPv6 addresses. The existing specifications do not explicitly say how to determine whether a given provider address is IPv4 or IPv6, and there are differing precedents about the method used to encode IPv4 addresses in messages that also contain IPv6 addresses. This document removes any ambiguity by specifying that MCAST-VPN routes always encode provider IPv4 addresses as four-octet addresses, and that the distinction between an IPv4 address and an IPv6 address is signaled solely by the length of the address field.},
}