I read the draft yesterday.
I wasn't surprised. That in itself was a surprise.
It's exactly what I thought the problem is from the beginning.
There was no big mystery requirement that I didn't understand.
The only thing I found weird was the belief that RFC4301 SPD
configuration had to be "h
On Chris' new use case, I don't think that's a new use case.
I think it's a requirement that spans all the use cases. The
solution must be able to handle network topology changes.
But we're not into requirements yet. Use cases first.
Thanks,
Steve
> -Original Message-
> From: Ulliott, Ch
Of course, you're right. The acronym DMVPN makes this
a very bad choice. Thanks for pointing that out.
I'll throw out a few ideas here:
Dynamic Direct VPN (DDVPN)
Shortcut VPN (SVPN)
Dynamic Scalable VPN (DSVPN)
Dynamic Efficient VPN (DEVPN)
Other ideas or comments on these are most welcome.
Th
Classification:UNCLASSIFIED
Good catch!
I've also thought of an additional use case, as I extend / change a network
within a data centre etc, it would be helpful if the crypto gateway could learn
of the new networks (through routing perhaps) and make them available through
the encrypted tunne
Hi Steve,
** **
>
> 1. I guess the problem statement is not just about lessening the number of
> configuration commands but also the fact that static configuration may not
> work in some cases. The spokes may get new addresses every time they come
> up (using DHCP/ PPPoE) and hence the communicat
Steve,
I do not think changing the name to "Dynamic Mesh VPN" is a good idea.
The first thing that is going to happen is that it is going to be
shortened to "DMVPN" and then we have conflict with Cisco DMVPN, which
would be confusing and also "DMVPN" is a registered trademark. It
would be best t
> -Original Message-
> From: hipsec-boun...@ietf.org [mailto:hipsec-boun...@ietf.org] On
> Behalf Of Henderson, Thomas R
> Sent: Monday, March 12, 2012 2:13 PM
> To: hip...@ietf.org
> Subject: [Hipsec] rfc5201-bis issue 32: normative text on when to have
> Domain Identifier
>
> http://tr
http://trac.tools.ietf.org/wg/hip/trac/ticket/30
This ticket states:
"Interactions with complex SPDs may result in weird effects. Need some
suggested text to clear this issue." I believe this tracker item is drawn from
Robert Moskowitz's IETF 80 presentation.
Note that for RFC 5202, there was
http://trac.tools.ietf.org/wg/hip/trac/ticket/32
This issue requests to add normative text on when to have a domain identifier.
I believe that this could be simply addressed by adding this statement to
section 5.2.9:
"A host MAY optionally associate its Host Identifier with a single Domain
Id
The new version of RFC5201-bis was just published at:
http://www.ietf.org/internet-drafts/draft-ietf-hip-rfc5201-bis-08.txt
This version had the following changes:
o Removed lingering references to SHA-1 as the mandatory hash
algorithm (which was changed to SHA-256 in the -02 draft vers
Hi,
Steve's document
http://tools.ietf.org/html/draft-ietf-ipsecme-p2p-vpn-problem-00 happens
to be (almost) the only thing on our agenda for Paris. I am sure once
you've read it you will have some comments to discuss on this list: do
the use cases make sense? Are there additional ones? Are t
Hello,
The UNH-IOL would like to ask the Working Group for feedback regarding an issue
we've observed.
This issue concerns how a Security Gateway handles IPv6 MTU restrictions and
fragmentations. Specifically, how should a SGW handle a received Packet Too
Big message, for an ESP packet which
12 matches
Mail list logo
