[rpd] New Proposal: Pv6 PI Clarification

[Lee Howard]

On 4/12/19 4:36 AM, JORDI PALET MARTINEZ via RPD wrote:
> Hi Jaco,
>   
> El 12/4/19 10:27, "Jaco Kroon" <jaco at uls.co.za> escribió:
>
>      Hi,
>      
>      On 2019/04/11 14:35, Lee Howard wrote:
>      >
>      > On 4/11/19 7:49 AM, Jaco Kroon wrote:
>      >> Hi,
>      >>
>      >> Use of ULA compared to RFC1918 addresses?
>      > There is little or no consensus around how to use ULA addresses.
>      Fair enough.  I never even contemplated it's use myself, and frankly, I
>      agree that if you can get public space, you should use it.  I suspect
>      one case where ULA would make sense if if you're receiving dynamic
>
> In my opinion this is a misconception. There is no reason for using dynamic (which we call non-persistent, to avoid confusion with DHCP thing) in IPv6. I suggest to read RIPE690. Ideally you could use ULAs for internal communications, as done in homenet, but this is not available in general, unless you use OpenWRT.

I completely disagree with your statement that "there is no reason for 
using dynamic" allocations.

I suspect I will continue to regret participating in drafting RIPE690 
for many years, even though it  would have been worse without my 
participating.

We need to improve renumbering, not freeze the Internet in place forever 
more.

I do not have a strong opinion on Network Prefix Translation, which I 
realize makes me a heretic among the IPv6 religious. But I'm not a 
fanatic, I'm an engineer.


>      while.  Here we can get around it by establishing an L2TP connection
>      from the client back to us and then delegatin a /56 or even a /48 back
>      over the L2TP connection.
>
> I guess this is a vendor specific issue ...
>      
...
>      Summary:  On dedicated links - no issues, everything works well, because
>      pretty much the delegations are static towards the customer, and
>      tracking beyond that static delegation isn't our responsibility, for
>      dynamic delegations though where we need to for various reasons know
>      which prefixes were delegated to which customers at what times ... big
>      problem.
>
> Again, vendor specific, there are many product in the market doing it correctly, never mind you use persistent and non-persistent prefixes for customers.

Engineers have to work around vendor feature gaps. Complaining that 
vendors stink is a time honored tradition. Someone chose a vendor whose 
product does not support something you want doesn't. Now we work around 
that--we don't tell people they're building their networks wrong.  
(Still stinging from discussion in v6ops)

Lee