Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

[Qiong <[e-mail]>]

Hi Leaf:

On Wed, Oct 12, 2011 at 3:24 PM, Leaf yeh <[e-mail]> wrote:

> Satoru -> I think we could have it.
> Tetsuya Murakami -> the decapsulation could be done for the packet having
> the tunnel end-point address as the destination or having the specific IPv6
> prefix as the destination.
>
> Does that mean BR needs to inject a route pointing to the BR subnet prefix,
> and using one interface address of BR as the next-hop of this prefix in the
> route? That means routes can direct the packets go to the right interface of
> the BR, right?
>
> Yes. In case of using the specific BR IPv6 prefix, BR needs to inject a
routing and identifying with one interface as the next-hop. And this kind of
prefix can be distributed in a similar way of RFC6334.

>
>
 Best Regards,
> Leaf
>
>
> -----Original Message-----
> From: Satoru Matsushima [mailto:[e-mail]]
> Sent: Tuesday, October 11, 2011 7:25 PM
> To: Leaf yeh
> Cc: Satoru Matsushima; Rémi Després; Ole Troan; Softwires-wg;
> [e-mail]
> Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation
> and double-translation
>
> On 2011/10/11, at 20:00, Leaf yeh wrote:
>
> >> Remi - >> A Destination address from a CE to the outside IPv4 Internet
> is:
> >>>> <--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
> >>>> +--------------------------+----+---------------+------------+---+
> >>>> |     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
> >>>> +--------------------------+----+---------------+------------+---+
> > Leaf -> In fact, I doubts we could have the same address mapping for both
> tunnel and translation. Supposed the address of tunnel end-points is
> preferred to be fixed, but the address for the translation could be
> variable.
> > Satoru -> I think we could have it.
> >
> > What is the definition of the IPv4 address in the above format? Is it the
> destination IPv4 address of any hosts outside 4rd IPv4 domain in the
> internet?
>
> I believe that the embedded IPv4 address should be an IPv4 address of a
> host on outside the domain.
>
> cheers,
> --satoru
>
> >
> >
> > Best Regards,
> > Leaf
> >
> >
> > -----Original Message-----
> > From: Satoru Matsushima [mailto:[e-mail]]
> > Sent: Tuesday, October 11, 2011 4:30 PM
> > To: Leaf yeh
> > Cc: Satoru Matsushima; Rémi Després; Ole Troan; Softwires-wg;
> [e-mail]
> > Subject: Re: [Softwires] Proposed Unified Address Mapping for
> encapsulation and double-translation
> >
> > Leaf, thanks for the summary.
> >
> > On 2011/10/10, at 20:34, Leaf yeh wrote:
> >
> >> Remi - >> a1- If the CE has an exclusive or shared IPv4 address:
> >>>> <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >
> >>>> +-------------+--------+---+---+----------------+------+-----+---+
> >>>> | IPv6 prefix |CE index| 0 | V |  IPv4 address  | PSID |  0  | L |
> >>>> +-------------+--------+---+---+----------------+------+-----+---+
> >> Ole - > putting the IPv4 address / port information at the end of the
> interface identifier will allow for > /64 support. > what's the L?
> >> Remi - Don't see what you found unclear.
> >>
> >>
> >> Question: Supposed the question is on the last field, named 'L', in the
> new address format.
> >>
> >
> > Since Remi's draft doesn't specify 'CE IPv6 prefix length', IPv6 prefix
> can't be self delimiting to extract IPv4 address and port-set ID in the case
> of double translation. That's my understanding. Is that correct?
> > As '4rd-a', and 4via6(draft-murakami-softwire-4v6-translation), the 'L'
> bits are not necessary because 'CE IPv6 prefix length' is defined through a
> domain, instead of 'L'.
> >
> >
> >>
> >> Remi - >> A Destination address from a CE to the outside IPv4 Internet
> is:
> >>>> <--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
> >>>> +--------------------------+----+---------------+------------+---+
> >>>> |     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
> >>>> +--------------------------+----+---------------+------------+---+
> >> Ole - this is a big change for encapsulation, where prior to this
> encapsulation means sending to a single destination.
> >> Remi - Copying an available IPv4 address at a fixed place isn't IMHO a
> "big change".
> >>
> >>
> >> Concern: Supposed the replacement of the 1st 64bits of the BR address
> with a subnet prefix is not for the tunnel case if the field of IPv4 address
> can be variable, right?
> >
> > I think that it could be a case where the BR address with a subnet prefix
> for the tunnel case. My concern rather than the BR address is that a CE
> should pick packets up which have 'V' in IID, even destined prefixes are
> delegated to nodes which are behind of the CE.
> >
> >
> >>
> >> In fact, I doubts we could have the same address mapping for both tunnel
> and translation. Supposed the address of tunnel end-points is preferred to
> be fixed, but the address for the translation could be variable.
> >>
> >
> > I think we could have it.
> >
> > cheers,
> > --satoru
> >
> >
> >>
> >> Best Regards,
> >> Leaf
> >>
> >>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Rémi Després
> >> Sent: Thursday, October 06, 2011 6:07 PM
> >> To: Ole Troan
> >> Cc: Softwires-wg
> >> Subject: Re: [Softwires] Proposed Unified Address Mapping for
> encapsulation and double-translation
> >>
> >>
> >> Le 6 oct. 2011 à 18:47, Ole Troan a écrit :
> >>
> >>> Remi,
> >>>
> >>> [...]
> >>>
> >>>> 2.
> >>>> (a)
> >>>> The IPv6 Source address of an IPv4 packet from a CE is:
> >>>>
> >>>> a1- If the CE has an exclusive or shared IPv4 address:
> >>>>
> >>>> <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 >
> >>>> +-------------+--------+---+---+----------------+------+-----+---+
> >>>> | IPv6 prefix |CE index| 0 | V |  IPv4 address  | PSID |  0  | L |
> >>>> +-------------+--------+---+---+----------------+------+-----+---+
> >>>
> >>> putting the IPv4 address / port information at the end of the interface
> identifier will allow for > /64 support.
> >>
> >> Could you explain more the requirement you have in mind?
> >>
> >>> what's the L?
> >>
> >> On the picture, L is 32 bits + Length(PSID).
> >> Don't see what you found unclear.
> >>
> >>>
> >>> you suggest that the first subnet of an allocation should be used for
> this purpose.
> >>
> >> Did I do this?
> >> Please explain because that's not, IMHO,  something to be done.
> >>
> >>> the first subnet is convenient to use for e.g. manual addressing (since
> it allows the :: short hand).
> >>> I do wonder if this has to be provisioned. e.g. some deployments may
> use the first subnet for the link between
> >>> CE and PE. (i.e. a /56 - 1 using the PD exclude option is used).
> >>
> >> See just above.
> >>
> >>>
> >>>> a2- If the CE has an IPv4 prefix:
> >>>>
> >>>> <--------- 64 ------------><8 ><-- L < 32 --><--- 48-L -----><8 >
> >>>> +-------------+--------+---+---+-------------+---------------+---+
> >>>> | IPv6 prefix |CE index| 0 | V | IPv4 prefix |         0     | L |
> >>>> +-------------+--------+---+---+-------------+---------------+---+
> >>>>
> >>>> (b)
> >>>> V is the mark that characterizes IPv6 packets that are in reality IPv4
> packets.
> >>>> Its value differs from any permitted value of this octet in IPv6 IIDs
>  (ref RFC 4291).
> >>>>
> >>>> It is understood that, if double Translation coexists with single
> translation, concerned ISPs may notify their CEs to use the U octet of RFC
> 6052 instead of V.
> >>>>
> >>>> An unambiguous mark is fortunately possible because currently
> permitted IIDs have in their first octet either bit6 = 0 (the "u" bit"), or
> bit6 = 1 and bit7= 0 (the "g" bit).
> >>>> With V having "u" = 1 (signifying Universal scope) AND "g" = 1,
> distinction is therefore deterministic.
> >>>>
> >>>> The proposed V is = 00000011.
> >>>> (With other values of this octet, other IID formats can be defined in
> case some would be useful in the future.)
> >>>>
> >>>> Note that, if and when a consensus is reached in Softwire, an
> extension of RFC 4291 will have to be submitted to 6MAN.
> >>>
> >>> or rather IEEE?
> >>
> >> IMHO, IEEE has nothing to do with a marker that is purposely an escape
> mechanism from the modified EUI-64 format of RFC 4291.
> >>
> >>> I am not convinced that "V" is needed.
> >>
> >> The point is more, IMHO, whether you have an objection to it (and in
> this case which one).
> >> Reason is that we are working for a consensus, and several are satisfied
> with the explanation that there are use cases where it is useful, and none
> where it is harmful.
> >>
> >>> you could even use the IANA OUI if pretty printing was required.
> >>
> >> The point is that it takes 32 bits which is too much to have IPv4
> address + PSID in the IID.
> >>
> >>
> >>>> (c)
> >>>> A Destination address from a CE to the outside IPv4 Internet is:
> >>>> <--------- 64 ------------>< 8 ><----   32 ----><--- 16 ----><8 >
> >>>> +--------------------------+----+---------------+------------+---+
> >>>> |     BR subnet prefix     | V  |  IPv4 address |      0     |32 |
> >>>> +--------------------------+----+---------------+------------+---+
> >>>
> >>> this is a big change for encapsulation, where prior to this
> encapsulation means sending to a single destination.
> >>
> >> Copying an available IPv4 address at a fixed place isn't IMHO a "big
> change".
> >>
> >>> if we also allow for a BR subnet prefix of /128 I'm OK with this (I
> think).
> >>
> >> I don't understand what you mean by "Subnet prefix of /128".
> >>
> >>
> >>>> Note that if double-translation CEs are notified to use U instead of
> V, the last octet becomes 0 per RFC  6052.
> >>>
> >>> how would a CE know if it was single or double translating?
> >>
> >> Presumably with a usual method, e.g. DHCPv6.
> >> Anything problematic with that?
> >>
> >>
> >>> e.g we could do:
> >>>
> >>> <--------- 64 ------------><--- 24 ------><----- 32 -------><--8 >
> >>> +-------------+--------+---+--------------------+------+-----+---+
> >>> | IPv6 prefix |CE index| S | 00-00-5E    |  IPv4 address  | PSID |
> >>> +-------------+--------+---+---+----------------+------+-----+---+
> >>>
> >>> we also need to handle the case where IPv6 prefix + CE index > 64.
> >>
> >> Please explain more your understanding of this requirement.
> >> (I personally believe we should avoid that.)
> >>
> >>> I suggest we then just put as much as the interface identifier that
> will fit.
> >>
> >>
> >> May I suggest that, to be more constructive, you could first express
> your objections to the proposed unified mapping, rather than making a number
> of new proposals whose justifications are sometimes hard to understand,
> >>
> >> Cheers,
> >> RD
> >>
> >>
> >>>
> >>> cheers,
> >>> Ole
> >>>
> >>>
> >> _______________________________________________
> >> Softwires mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/softwires
> >> _______________________________________________
> >> Softwires mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/softwires
> >
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>