Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs

From: Ole Troan <[email-masked]>
Date: Thu, 24 Jan 2013 17:27:18 +0100

hi,

can we please keep discussion on the list. not via the issue tracker?

does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep current text.)

cheers,
Ole

On Jan 24, 2013, at 17:23 , softwire issue tracker <[email-masked]> wrote:

> #19: IPv4 address superfluous in MAP-E Interface IDs
> 
> Changes (by [email-masked]):
> 
> * priority:  trivial => major
> * status:  closed => reopened
> * resolution:  wontfix =>
> 
> 
> Comment:
> 
> Value of having the PSID in MAP-E IIDs for maintenance isn't clear at all:
> - PSID length isn't determined in IIDs (there can be an unknown number of
> trailing zeroes)
> - all PSID bits are already readable in the first 64 bits
> 
> Suggestion to close the issue:
> - keep IPv4 addresses in IIDs (they contains some bits that aren't in the
> first 64 bits)
> - don't keep the PSID in IIDs (insufficiently justified complexity)
> 
> -- 
> -------------------------+-------------------------------------------------
> Reporter:               |       Owner:  draft-ietf-softwire-
>  [email-masked]   |  [email-masked]
>     Type:  defect       |      Status:  reopened
> Priority:  major        |   Milestone:
> Component:  map-e        |     Version:
> Severity:  Candidate    |  Resolution:
>  WG Document            |
> Keywords:               |
> -------------------------+-------------------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#comment:4>
> softwire <http://tools.ietf.org/softwire/>
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 24 Jan 2013 18:09:02 +0100

> can we please keep discussion on the list. not via the issue tracker?

- the issue tracker was AFAIK created by the chairs to be used.
- I was answering a new input from Ole on the issue tracker itself, and containing a question (see below).

(Yet, if the chairs suggest to now avoid using the tracker, I will act accordingly.)

> (if I don't hear anything from anyone else, I'll default to keep current text.)

Ole's point was:
"The interface-id has to be something. It is useful to put PSID and IPv4 address in there for troubleshooting purposes.
Do you have a proposal for what you'd rather want it to be?
As the value is there largely for "pretty printing", just pick something."

My comment has been:
"Value of having the PSID in MAP-E IIDs for maintenance isn't clear at all:
• PSID length isn't determined in IIDs (there can be an unknown number of trailing zeroes)
• all PSID bits are already readable in the first 64 bits
Suggestion to close the issue: 
• keep IPv4 addresses in IIDs (they contains some bits that aren't in the first 64 bits)
• don't keep the PSID in IIDs (insufficiently justified complexity)"

Ole's reason to ignore this proposed simplification hasn't been given.

Comments welcome.

RD

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 24 Jan 2013 11:51:47 -0600

> - the issue tracker was AFAIK created by the chairs to be used.

Authors don't like the issue tracker. No author likes it.
Because of this in several WGs, issue tracker is not used.

I don't know why?

Regards,

Behcet

- I was answering a new input from Ole on the issue tracker itself, and
> containing a question (see below).
>
> "The interface-id has to be something. It is useful to put PSID and IPv4
> address in there for troubleshooting purposes.
> >> Ticket URL: <
> http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#comment:4>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 24 Jan 2013 15:08:35 -0500

This caught my eye too. Why repeat the PSID?

>> - don't keep the PSID in IIDs (insufficiently justified complexity)
...

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Jan 2013 23:44:56 +0100

Tom,

> This caught my eye too. Why repeat the PSID?

the reason I got, if my memory serves me correctly, is that it allows a intermediate box to look at the PSID,
without knowing the mapping rules (which it must to look at the PSID in the first 64 bits.

cheers,
Ole

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 25 Jan 2013 08:56:17 +0900

> This caught my eye too. Why repeat the PSID?

Does anyone have the reason of it must not?

cheers,
--satoru

---

From: Tom Taylor <[email-masked]>
Date: Thu, 24 Jan 2013 19:19:56 -0500

I am not sure that's of any use to intermediate nodes without the rest 
of the rules, but I suppose you have to put something unique into the IID.

I have one concern indirectly related to this. Section 6 still says:

    If the End-user IPv6 prefix length is larger than 64, the most
    significant parts of the interface identifier is overwritten by the
    prefix.

I believe that makes the IID non-conformant to RFC 6052.

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Jan 2013 01:22:36 +0100

Tom,

> I believe that makes the IID non-conformant to RFC 6052.

it uses an IID similar to 6052... any better suggestion?
(my personal view is that 6052 got things wrong with the U octet, but that's another matter)

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Fri, 25 Jan 2013 13:09:52 -0500

We have two choices on this one:

a) prohibit the use of an end user IPv6 prefix of length greater than 64 
bits;

b) simply remove the reference to RFC6052, or qualify it by saying that 
the IID conforms to Section 2.2 of RFC 6052 except in the case of end 
user IPv6 prefixes of length greater than 64 bits.

Any preferences?

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Jan 2013 19:36:44 +0100

Tom,

> a) prohibit the use of an end user IPv6 prefix of length greater than 64 bits;
> 
> b) simply remove the reference to RFC6052, or qualify it by saying that the IID conforms to Section 2.2 of RFC 6052 except in the case of end user IPv6 prefixes of length greater than 64 bits.
> 
> Any preferences?

RFC6052 permits prefix lengths longer than /64. which isn't at odds with the current text.
MAP of course permits any prefix length, while 6052 is limited to only 6 sets.

the current text do state that the format is "based on", rfc6052, it does not say it uses the format from rfc6052.
nor is 6052 a normative reference. what if we change s/based on/similar to/ ? is that clearer?

cheers,
Ole

---

From: Tom Taylor <[email-masked]>
Date: Fri, 25 Jan 2013 14:25:35 -0500

That should be OK.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 25 Jan 2013 20:13:16 +0000

>Does anyone have the reason of it must not?

I guess the question should be the converse, why should it be duplicated,
not why it shouldn¹t be.
I had direct discussions with Ole and other authors a long time ago, but I
fail to see the rationale on why it is repeated.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 25 Jan 2013 20:14:46 +0000

Could we make this explicit the prefix lengths can be of any arbitrary
length? Or bit boundaries? Or nibble boundaries?

Thanks

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 25 Jan 2013 20:20:19 +0000

>a) prohibit the use of an end user IPv6 prefix of length greater than 64

I would think that is restrictive.

>user IPv6 prefixes of length greater than 64 bits.

That would be fine, but it is not clear now in the current draft if we
should skip the u bits
or overwrite them if the prefix length is greater than 64.

Senthil

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Jan 2013 21:22:17 +0100

Senthil,

> length? Or bit boundaries? Or nibble boundaries?

we could... MAP has to handle whatever the operator decided to delegate or assign to the end-user.
can you propose text?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Jan 2013 21:23:30 +0100

> or overwrite them if the prefix length is greater than 64.

the current draft says overwrite. rfc6052 implies overwrite (and goes on to say it is the operator's responsibility to ensure the u-octet is there).

cheers,
Ole

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 25 Jan 2013 20:33:13 +0000

As an implementor, I would like to see the prefix length to be either in
byte boundaries or atleast nibble boundaries.
It makes life a little easier.

How about this:

"The prefix lengths can be of arbitrary length and does not have to be in
byte boundaries.
The MAP devices SHOULD allow the prefixes of any length less than 96 bits.
If the prefix length
Is greater than 64 bits, the u bits (bits 64-72) should be overwritten."

Note I said "should" be overwritten (or MUST), because a loose terminlogy
will allow the wiggle room to interpret it either way, which should be
avoided.

Thanks
Senthil

On 1/25/13 3:22 PM, "Ole Troan" <[email-masked]> wrote:

>>> RFC6052 permits prefix lengths longer than /64. which isn't at odds
>>>with
>>> the current text.
>>> MAP of course permits any prefix length, while 6052 is limited to only
>>>6
>>> sets.
>>> 
>>> the current text do state that the format is "based on", rfc6052, it
>>>does
>>> not say it uses the format from rfc6052.

---

From: Rémi Després <[email-masked]>
Date: Sat, 26 Jan 2013 11:50:40 +0100

Hi, Senthil,

> I would think that is restrictive.

Why?
RFC 4291 says "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long ...".
Doesn't this imply that MAP subnet prefixes always have 64 bits too?

RD

---

From: Tom Taylor <[email-masked]>
Date: Sun, 27 Jan 2013 11:32:46 -0500

Rémi has a point. RFC 4291 doesn't seem to leave wiggle room. Section 
2.5.1 says:

    For all unicast addresses, except those that start with the binary
    value 000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format.

However, the modified EUI-64 requirement is negotiable. Appendix A of 
RFC 4291 says:

    Links without Identifiers

    There are a number of links that do not have any type of built-in
    identifier.  The most common of these are serial links and configured
    tunnels.  Interface identifiers that are unique within a subnet
    prefix must be chosen.

The MAP case is an example of "configured tunnels", I'd say. So there is 
no requirement on the specific contents of the last 64 bits except that 
the u bit has to be zero, since the IID isn't guaranteed to be 
universally unique.

This leaves the requirement that the IID be 64 bits long. I can't see 
how to get around this one without going to 6man and asking for a change.

Just a  further thought: requiring that the first subnet (the all-zeroes 
subnet) be reserved for MAP doesn't mean much if the prefix doesn't 
contain a subnet field. Does this provision have to change if the prefix 
reaches 64 bits in length?

Arithmetic example of what I would consider reasonable:
- /56 assigned to the subscriber
- sharing ratio = 64, implying 6 bits for the PSID field
- BMR shared only between CEs sharing the same IPv4 address, hence no 
address bits needed in the EA bits field
=> 6 EA bits, Rule IPv6 prefix is a /50.

Here's an alternative example (assuming we can say something sensible 
about what gets reserved if there is no subnet ID field):
- /64 assigned to the subscriber
- same assumptions as above on sharing
=> Rule IPv6 prefix is a /58

Tom Taylor

---

From: Rémi Després <[email-masked]>
Date: Mon, 28 Jan 2013 09:40:02 +0100

2013-01-27  17:32, Tom Taylor <[email-masked]> :

> Rémi has a point. RFC 4291 doesn't seem to leave wiggle room. Section 2.5.1 says:
> 

This sentence, because it applies to ALL unicast addresses that don't start with 000, does apply to MAP addresses.

Suggestion: delete any reference to subnet IDs longer than /64. 
AFAIK, that's enough.

Regards,
RD  

> 
> However, the modified EUI-64 requirement is negotiable. Appendix A of RFC 4291 says:
> 
> The MAP case is an example of "configured tunnels", I'd say. So there is no requirement on the specific contents of the last 64 bits except that the u bit has to be zero, since the IID isn't guaranteed to be universally unique.
> 
> This leaves the requirement that the IID be 64 bits long. I can't see how to get around this one without going to 6man and asking for a change.
> 
> Just a  further thought: requiring that the first subnet (the all-zeroes subnet) be reserved for MAP doesn't mean much if the prefix doesn't contain a subnet field. Does this provision have to change if the prefix reaches 64 bits in length?
> 
> - BMR shared only between CEs sharing the same IPv4 address, hence no address bits needed in the EA bits field
> Here's an alternative example (assuming we can say something sensible about what gets reserved if there is no subnet ID field):

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Jan 2013 10:16:24 +0100

Remi, Tom,

> Suggestion: delete any reference to subnet IDs longer than /64. 

the choice of prefix length for the End-user IPv6 prefix is an operator's choice, and not something we should limit in specification.
for the purpose of MAP it could very well be a /128 for that matter.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Mon, 28 Jan 2013 10:26:12 +0100

>>> Rémi has a point. RFC 4291 doesn't seem to leave wiggle room. Section 2.5.1 says:

(*)

> the choice of prefix length for the End-user IPv6 prefix is an operator's choice,

OK

> and not something we should limit in specification.

Different understanding of (*).
RD

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 28 Jan 2013 13:51:10 +0000

Hi,

the IPv4 and PSID in the IID are particularly useful in cases of address
independence (ie 1:1). As said previously, the benefit is primarily in the
ability an operational facilitation, where an operator can easily
see/observe what IPv4 and PSID is being used by a given customer. This is
easier than to look at the v6 prefix and use some magic decoder ring.
In addition, it has the desirable characteristic of creating an IID.

+1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit)
field format.

Regards,
Woj.

---

From: [email-masked]
Date: Tue, 29 Jan 2013 10:38:01 +0800

Hi,

  Keeping PSID in IIDs seems repeated from the aspect of 128-bit IPv6 
address, but from the aspect of 64-bit IIDs, IPv4 address and PSID 
guarantee IIDs to be universally unique. 

  So, +1 Keeping the IPv4 and PSID in IIDs.

BRs
Linda Wang

Wojciech Dec <[email-masked]> 
发件人:  [email-masked]
2013-01-28 21:51

收件人
Ole Troan <[email-masked]>
抄送
"[email-masked] WG" <[email-masked]>, [email-masked]
主题
Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E 
Interface IDs

Hi,

Regards,
Woj.

does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep current 
text.)

cheers,
Ole

---

From: Qi Sun <[email-masked]>
Date: Tue, 29 Jan 2013 14:00:56 +0800

Woj ,

> the IPv4 and PSID in the IID are particularly useful in cases of address independence (ie 1:1). 

Now that IPv4 and PSID is put in the IPv6 address, why is it a case of address independence?

Best Regards,
Qi Sun

On 2013-1-28, at 下午9:51, Wojciech Dec wrote:

> Hi,
> 
> the IPv4 and PSID in the IID are particularly useful in cases of address independence (ie 1:1). As said previously, the benefit is primarily in the ability an operational facilitation, where an operator can easily see/observe what IPv4 and PSID is being used by a given customer. This is easier than to look at the v6 prefix and use some magic decoder ring.
> +1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) field format.
> 
> Regards,
> Woj.
>

---

From: Maoke <[email-masked]>
Date: Tue, 29 Jan 2013 16:09:37 +0900

2013/1/29 Qi Sun <[email-masked]>

> independence (ie 1:1).

IPv4-address independent MAP rule .. ;-) - maoke

---

From: Maoke <[email-masked]>
Date: Tue, 29 Jan 2013 16:14:10 +0900

2013/1/29 Maoke <[email-masked]>

> IPv4-address independent MAP rule .. ;-) - maoke

sorry IPv4-address independent MAP rule-IPv6-prefix. :P - maoke

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 29 Jan 2013 09:00:27 +0000

Correct. Thanks Maoke.

---

From: Rémi Després <[email-masked]>
Date: Tue, 29 Jan 2013 10:37:32 +0100

The key is "keep it simple", with neither IPv4 addresses nor PSIDs in MAP-E IIDs. 
More explanations below.

> the IPv4 and PSID in the IID are particularly useful in cases of address independence (ie 1:1). As said previously, the benefit is primarily in the ability an operational facilitation, where an ope…

(a) The IPv4 address already readable in the encapsulated IPv4 packet (the subject is only MAP-E, not MAP-T or 4rd).
(b) With the proposed IID format, the length of the PSID cannot be determined without looking at the applicable mapping rule. (As already noted, the number of zeroes at the end of the PSID isn't specified in the address). 
(c) Once the rule is looked at, getting the PSID is easy (no more magic needed than to get find the PSID length ;-)).
 
> In addition, it has the desirable characteristic of creating an IID.

A constant IID was the logic proposal for the original Encapsulation solution (then called "4rd" before becoming "MAP-E", ref. tools.ietf.org/html/draft-murakami-softwire-4rd-01).
It is only when we tried to merge -E it with -T that we abandoned this simplicity. 
(Incidentally, to avoid limitation (b) above, we introduced that at that time a PSID-length field in IIDs (ref. www.ietf.org/mail-archive/web/softwires/current/msg02994.html), but this complexity would be superfluous for MAP-E.) 

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Jan 2013 10:50:11 +0100

Remi,

> (a) The IPv4 address already readable in the encapsulated IPv4 packet (the subject is only MAP-E, not MAP-T or 4rd).

yes.

> (b) With the proposed IID format, the length of the PSID cannot be determined without looking at the applicable mapping rule. (As already noted, the number of zeroes at the end of the PSID isn't sp…

correct.

> (c) Once the rule is looked at, getting the PSID is easy (no more magic needed than to get find the PSID length ;-)).

unless you are in 1:1 mode.

> It is only when we tried to merge -E it with -T that we abandoned this simplicity. 

simplicity for whom?
the interface-id is constant for the MAP node. I have not heard any implementors state it is hard enough to be worth
arguing over whether to write an IPv4 address in there rather than a set of zeroes.
what is simplest for the operator? having to calculate the IPv4 address based on the rules? or look at the IPv4 address in the IID?

> (Incidentally, to avoid limitation (b) above, we introduced that at that time a PSID-length field in IIDs (ref. www.ietf.org/mail-archive/web/softwires/current/msg02994.html), but this complexity w…

to summarise, your proposal is to overlap with the subnet router anycast address, i.e. all zeroes?

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 29 Jan 2013 10:41:21 +0000

> The key is "keep it simple", with neither IPv4 addresses nor PSIDs in

An IID needs to be there. The IPv4+PSID is computed in any case and makes
such a decent IID, without increasing implementation complexity. Peeking
across layers, possibly encapsulation layers to obtain such useful,
according to some operators, info is not conductive to making things
simpler for anyone operating the network. It also does not complicate
matters for those operators not planning to make any use of this info.

As I mentioned, having a fixed length IPv4+PSID would be my preference.

Regards,
Woj.

> (a) The IPv4 address already readable in the encapsulated IPv4 packet (the
> subject is only MAP-E, not MAP-T or 4rd).
> (b) With the proposed IID format, the length of the PSID cannot be
> determined without looking at the applicable mapping rule. (As already
> noted, the number of zeroes at the end of the PSID isn't specified in the
> address).
> (c) Once the rule is looked at, getting the PSID is easy (no more magic
> needed than to get find the PSID length ;-)).
>
>
> A constant IID was the logic proposal for the original Encapsulation
> solution (then called "4rd" before becoming "MAP-E", ref.
> tools.ietf.org/html/draft-murakami-softwire-4rd-01).
> (Incidentally, to avoid limitation (b) above, we introduced that at that
> time a PSID-length field in IIDs (ref.
> www.ietf.org/mail-archive/web/softwires/current/msg02994.html), but this
> complexity would be superfluous for MAP-E.)
>
> Regards,
> RD
>
>
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 29 Jan 2013 14:59:32 +0000

+1 in keeping both.

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Monday, January 28, 2013 9:38 PM
To: Wojciech Dec <[email-masked]>
Cc: Softwires-wg list <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: [Softwires] 答复: Re:  [softwire] #19: IPv4 address superfluous in
MAP-E Interface IDs

>发件人:  [email-masked] 21:51
>收件人
>Ole Troan <[email-masked]> 抄送
>"[email-masked] WG" <[email-masked]>, [email-masked]
>independence (ie 1:1). As said previously, the benefit is primarily in
>the ability an operational facilitation, where an operator can easily
>see/observe what IPv4 and PSID is being used
> by a given customer. This is easier than to look at the v6 prefix and
>use some magic decoder ring.
>On Jan 24, 2013, at 17:23 , softwire issue tracker
><[email-masked] <mailto:[email-masked]>>
>wrote:
>
>> Ticket URL: 
>><http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#comment:4>

---

From: Rémi Després <[email-masked]>
Date: Tue, 29 Jan 2013 16:24:22 +0100

> unless you are in 1:1 mode.

There is a point here which AFAIK has never been discussed before.  
(A reference is welcome if there is one I missed).

This point concerns 1:1 mappings (if needed in MAP-E), when combined with shared IPv4 addresses: 
- To be assigned a shared address, a CE needs a PSID in addition to its IPv4 address.
- Currently, this PSID cannot be found in the 1:1 rule itself (ref. http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01.)

The approach that is in my understanding implied by Ole is that each concerned CE will be delegated a MAP-E IPv6 prefix, in addition to that used for native IPv6 addressing, with the PSID in it. (The detailed format isn't specified yet AFAIK, but specifying one is possible.) 

Another approach, AFAIK much simpler in operations, is to add a rule parameter to assign a PSID, present in 1:1 rules. 
This eliminates the need to delegate to each CE an additional IPv6 prefix. 

Example:
. CE delegated prefix: 2001:db8:0:100::/56
. BMR for this CE
  Rule IPv6 prefix   : 2001:db8:0:100:/56
  EA-bits length     : 0
  Rule IPv4 prefix   : 1.1.1.1/32
  PSID               : 0x11   

Conclusion: if 1:1 mappings are part of MAP-E, add a PSID parameter in 1:1 mapping rules.
(Otherwise: (1) specify detailed formats of MAP-E specific delegated prefixes > /64; (2) explain why delegated prefixes used for IPV6 aren't found sufficient.)

Regards,
RD

>>>> 2001:db8::1
>>>> Rule IPv6 prefix: 2001:db8::1/128
>>>> Rule IPv4 prefix: 1.1.1.1/32
>>>> EA-bits length: 0

> to summarise, your proposal is to overlap with the subnet router anycast address, i.e. all zeroes?

This has been discussed long ago. Following a comment made by Wojciech if I remember right, the constant value can be a 1 to avoid any risk of conflict with the subnet router anycast address.

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Jan 2013 18:14:56 +0100

Remi,

> (A reference is welcome if there is one I missed).

this has been covered in the 1:1 discussions.

> - Currently, this PSID cannot be found in the 1:1 rule itself (ref. http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01.)

there is no separate 1:1 rule. PSID is defined in OPTION_MAP_PORTPARAMS.

> The approach that is in my understanding implied by Ole is that each concerned CE will be delegated a MAP-E IPv6 prefix, in addition to that used for native IPv6 addressing, with the PSID in it. (T…

no, then you have misunderstood.

> Conclusion: if 1:1 mappings are part of MAP-E, add a PSID parameter in 1:1 mapping rules.

yes, that's how I at least have intended it to be.

> (Otherwise: (1) specify detailed formats of MAP-E specific delegated prefixes > /64; (2) explain why delegated prefixes used for IPV6 aren't found sufficient.)

MAP should not put any restrictions for what prefix length a provider wishes to delegate to an end user.
it should also allow the use of a separate address (or prefix) for MAP. I don't see why we want to artificially
restrict the prefix lengths.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Tue, 29 Jan 2013 19:24:36 +0100

Ole,

Thanks for the clarification.
More comments inline.

> this has been covered in the 1:1 discussions.

Let's proceed without a reference. (This isn't one.)

> there is no separate 1:1 rule. PSID is defined in OPTION_MAP_PORTPARAMS.

Acknowledged. (I had missed this parameter.)

> no, then you have misunderstood.

Acknowledged.

> yes, that's how I at least have intended it to be.

Acknowledged.

> restrict the prefix lengths.

Conclusion: it is now clarified that, even if 1:1 with shared addresses has to be covered, there is no need for any MAP-E prefix longer than 64 bits.

Consequence: the sentence about overwriting "the most significant parts of the interface identifier" in case of such extra-long prefixes, isn't needed. 
It should be deleted. 

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Jan 2013 19:54:27 +0100

Remi,

> Consequence: the sentence about overwriting "the most significant parts of the interface identifier" in case of such extra-long prefixes, isn't needed. 

that doesn't follow, and the above discussion is a different point.
can we please hold back a little and let other people in the working group voice their opinion?
cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Jan 2013 09:47:15 +0100

> can we please hold back a little and let other people in the working group voice their opinion?

To make progress, I feel it should be acceptable to continue to:
- ask for clarifications on some points that IMHO remain obscure (e.g. the purpose of overwriting "the most significant parts of the interface identifier" for CE IPv6 prefixes of lengths > 64, especially since it conflicts with RFC 6052).
- react to statements or assumptions that are AFAIK inaccurate (e.g. that, with MAP-E IID formats as specified, maintenance could determine PSID values from IIDs alone.)

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Jan 2013 10:04:38 +0100

Remi,

> - ask for clarifications on some points that IMHO remain obscure (e.g. the purpose of overwriting "the most significant parts of the interface identifier" for CE IPv6 prefixes of lengths > 64, espe…

I don't quite agree that it conflicts, but looking back at comments from several people it might be best to remove the 6052 reference.

> - react to statements or assumptions that are AFAIK inaccurate (e.g. that, with MAP-E IID formats as specified, maintenance could determine PSID values from IIDs alone.)

agree, but you can get a 'fair' idea. given that both the IPv4 address and PSID are fixed length fields at fixed offsets.
I'm defending status quo largely because that gives me the least amount of work. ;)

please convince the working group of your scheme, and provide the text, and I'll put that in the document.
so far I have seen more support for the existing scheme than the "::1" though.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 30 Jan 2013 10:56:30 +0100

> I don't quite agree that it conflicts, but looking back at comments from several people it might be best to remove the 6052 reference.

Removing the reference does eliminate the conflict.
What remains unknown is the purpose of IPv4-address and PSID fields if they may be partially overwritten, e.g. with IPv6 prefixes of 96 or 120 bits.

> agree,

Good.

> but you can get a 'fair' idea. given that both the IPv4 address and PSID are fixed length fields at fixed offsets.

'Fair' idea is unclear but yes, if the PSID length is known to be fixed, one can find the PSID (only in that case). 

> so far I have seen more support for the existing scheme than the "::1" though.

Provided the IID "overwriting" is clarified (see above), I agree that whatever the majority prefers will become the standard, even if unnecessarily redundant. 
My contribution is simply to suggest an application of the KISS principle.

Regards,
RD