Hi Margaret,
On 2009-02-05 00:12, Margaret Wasserman wrote:
> Hi Brian and James,
>
> On Jan 26, 2009, at 4:39 PM, Brian E Carpenter wrote:
>
>> James,
>>
>> On 2009-01-25 13:29, james woodyatt wrote:
>> ...
>>> While SHIM6 is complicated, I would say that its main detraction as an
>>> alternative to NAT66 is that it doesn't have a very good incremental
>>> deployment story. It is, however, not the only way to design a shim
>>> layer aimed at giving us multi-homing and provider independence. I
>>> suspect there are better ways to address that problem, which would still
>>> require updates to existing IPv6 node implementations while allowing for
>>> a more incremental deployment than SHIM6 does.
>>
>> I'd be interested to see a proof of concept that this can be done. There
>> was quite a lot of discussion of alternative approaches before the shim6
>> direction was chosen, reflected in RFC 4177, 4218 and 4219.
>
> Does one of you want to write a draft about how an enterprise network
> could achieve address independence using SHIM6 and present it at the BOF
> as an alternative solution to this problem? I am not fully up-to-date
> on the shim6 work, and I don't think I understand how it would provide
> address independence.
>
> In case we have a terminology issue... I would define address
> independence as:
>
> - The IP addresses in use inside the local network (for nodes, ACLs,
> logs) do not need to be renumbered if the ISP changes a site's external
> address prefix.
> - The IP addresses in use inside the local network (for nodes, ACLs,
> logs) do not need to be renumbered when a site changes ISPs.
> - It is not necessary for an administrator to convince an ISP to route
> his or her internal addresses.
The thing is, shim6 was not invented to satisfy these properties.
It was invented to deal with two "givens" as they appeared
at the time:
(1) The IPv6 model assumes that a site connected to N ISPs will
operate with N simultaneous PA prefixes.
(2) Nothing will change in the BGP4 model. Despite all that's
going on in RRG, this assumption still seems valid for now.
The registries have chosen to complicate (1) by giving out
PI prefixes to a certain number of large sites. Also, the IETF
has complicated (1) by inventing ULAs (since site-local was
clearly broken). However, neither of those changes fundamentally
affects the shim6 model.
[Why not? ULA is simply orthogonal to shim6. PI doesn't
break shim6; it's semantically identical to PA as far as
the remote site is concerned. A user on a PI site still
gets benefit from running shim6, when communicating with
a shim6 host in a PA site.]
So, where does that leave a shim6 site in relation to your three
properties:
>> - The IP addresses in use inside the local network (for nodes, ACLs,
>> logs) do not need to be renumbered...
Shim6 doesn't help in itself. Use ULAs for all internal purposes,
particularly for everything involving configuration and management.
>> - It is not necessary for an administrator to convince an ISP to route
>> his or her internal addresses.
Again, use ULAs for all internal purposes. Use one PA prefix per
ISP for all external communication, with shim6 to handle failover.
No need to convince your ISPs of anything.
The stateful firewall issue that has been raised for shim6 remains
real, but it may well arise for other address-independent
scenarios as well, because stateful firewalls are intrinsically
address-dependent.
Getting back to your question:
>> Does one of you want to write a draft about how an enterprise network
>> could achieve address independence using SHIM6
Maybe get one of the main shim6 developers to do that?
Marcelo, are you here?
Brian
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
