Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt

["cb.list6" <[e-mail]>]

On Sat, May 25, 2013 at 10:33 PM, Owen DeLong <[e-mail]> wrote:
>
> On May 25, 2013, at 13:26 , cb.list6 <[e-mail]> wrote:
>
>
> On May 25, 2013 11:43 AM, "Owen DeLong" <[e-mail]> wrote:
>>
>>
>> On May 24, 2013, at 11:45 , Alexandru Petrescu
>> <[e-mail]> wrote:
>>
>> > Le 23/05/2013 23:08, Mark Smith a écrit :
>> >> Hi,
>> >>
>> >>
>> >> Suggested changes:
>> >>
>> >>
>> >>
>> >> 1. Introduction
>> >>
>> >> "... for delegating IPv6 prefixes to a LAN."
>> >>
>> >>
>> >> to
>> >>
>> >> ""... for delegating IPv6 prefixes to a single LAN interface."
>> >>
>> >> Generally I think this intro text should make it a bit clearer that
>> >> these methods are only extending the /64 to a single LAN interface.
>> >
>>
>> How can that work in the real world?
>>
>> For example, with my iPhone 5 running on VZW, I seem to get the same /64
>> over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the actual
>> cellular interface), BlueTooth (mobile hotspot), and USB (mobile hotspot).
>>
>> From my perspective that's 3 LAN interfaces and a WAN interface sharing
>> the
>> same /64.
>>
>
> At the same time?
>
>
> Yes..
>
> In any event, that implementation you mentioned is not publicly documented.
> The folks at Apple and Verizon are welcome to share their wisdom on this
> topic.
>
> Agreed. I wish they would/hope they do. However, bottom line, it's running
> code today.
>
> In any event, the work of this draft is to  use the open ietf process to get
> folks on the same page so the wheel does not get reinvented several times in
> a vacume.
>
>
> Agreed. However, that doesn't mean we need to invent an inferior wheel.
>
> Owen
>

well, we ship what gets rough consensus, not what is "best" for some
value of "best"

Back in the archives, we scoped the scenario to be one routed
down-link due to folks concerns about loops that would result from
having multiple interfaces up with the same prefix.

i think the discussion was somewhere around here and how NDproxy was
not acceptable

http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.html and
http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.html

CB

>