Hi All,
I support Ray position.
Maybe this drafts solves some situation but I believe it might bring
more problems than solutions.
regards,
Alejandro,
On 10/3/12, Ray Hunter v6...@globis.net wrote:
I have read the draft and don't see how it advances Homenet.
IMHO If an MSP wants to
On Oct 26, 2012, at 24:29 , Teco Boot t...@inf-net.nl wrote:
Opinions?
Seems like a straight-up job for IPsec, which is why RFC 6092 has section 3.2.4
IPsec and Internet Key Exchange (IKE).
--
james woodyatt j...@apple.com
core os networking
___
Op 29 okt. 2012, om 18:21 heeft Michael Richardson het volgende geschreven:
Teco == Teco Boot t...@inf-net.nl writes:
Teco More thoughts on this scenario. Assume the company has many branch
Teco offices (e.g. 1000 small sites, with 2001:::/48 from ISP),
Teco where main
Op 25 okt. 2012, om 18:30 heeft Michael Thomas het volgende geschreven:
On 10/23/2012 11:01 AM, james woodyatt wrote:
On Oct 23, 2012, at 08:20 , Michael Thomas m...@mtcc.com wrote:
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
Can you explain why this behaviour, combined with the prefer
On Thu, Oct 25, 2012 at 11:20 PM, Michael Richardson
mcr+i...@sandelman.cawrote:
LC Solution: from the border router which discovered the DNS entries
for
LC tvservice.jp, inject those DNS servers into the mesh with a tag
that they
LC only be used for tvservice.jp, and pass that
Hi,
Now - if we want to make this in a routed network where the VPN tunnel is
not terminated on the device itself, then RFC 3484/RFC6724 are not
sufficient.
Even in such a case, you can configure manually the policy table on each host
to meet the needs of such source address selection. This
On 10/24/2012 11:25 PM, Arifumi Matsumoto wrote:
Hi,
Now - if we want to make this in a routed network where the VPN tunnel is
not terminated on the device itself, then RFC 3484/RFC6724 are not
sufficient.
That was, in fact, what I was thinking about.
Even in such a case, you can configure
Lorenzo Colitti lore...@google.com wrote:
In the walled garden situation, however, if I had to hide the
records (which I think is fundamentally broken, but...), then I'd have
NS delegations from the public DNS into name servers that live in my
walled garden. So, you
On 10/23/2012 11:01 AM, james woodyatt wrote:
On Oct 23, 2012, at 08:20 , Michael Thomas m...@mtcc.com wrote:
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
Can you explain why this behaviour, combined with the prefer matching
interface rule in RFC 3484, is not sufficient? If not, then there
RJ Atkinson rja.li...@gmail.com wrote:
RJ It might be useful for James Woodyatt's notes about these
RJ technical issues to get written up as an Informational RFC, to
RJ help document the technical issues/operational issues for any
RJ new participants here (and more generally for
Lorenzo Colitti lore...@google.com wrote:
That solves the routing problem. But, what about the naming
problem? (whose DNS server do you use?)
LC NPT66 doesn't solve that either, right?
LC I believe the DNS problem needs to be solved using split DNS at
LC the domain
On Thu, Oct 25, 2012 at 8:20 AM, Michael Richardson
mcr+i...@sandelman.cawrote:
In the walled garden situation, however, if I had to hide the
records (which I think is fundamentally broken, but...), then I'd have
NS delegations from the public DNS into name servers that live in my
walled
On 22 Oct 2012, at 19:57, james woodyatt j...@apple.com wrote:
I would say that it MUST be deprecated by the arch document.
The arch document is Informational and contains no RFC 2119 keywords.
Ray
___
homenet mailing list
homenet@ietf.org
On 23 Oct 2012, at 09:50, Lorenzo Colitti lore...@google.com
wrote:
It can't deprecate it, but it can say that NPT66 is not supported in the
homenet architecture.
Indeed.
Ray
___
homenet mailing list
homenet@ietf.org
On 23 Oct 2012, at 09:54, Ray Bellis ray.bel...@nominet.org.uk wrote:
On 23 Oct 2012, at 09:50, Lorenzo Colitti lore...@google.com
wrote:
It can't deprecate it, but it can say that NPT66 is not supported in the
homenet architecture.
Indeed.
We can capture those sentiments in -07, and
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas m...@mtcc.com
mailto:m...@mtcc.com wrote:
No, sorry. Corporate VPN's using v6 and the lack of a coherent source
address selection mechanism causes breakage in bizarre and unpredictable ways.
Op 23 okt. 2012, om 17:20 heeft Michael Thomas het volgende geschreven:
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas m...@mtcc.com
mailto:m...@mtcc.com wrote:
No, sorry. Corporate VPN's using v6 and the lack of a coherent source
On 10/23/2012 10:25 AM, Teco Boot wrote:
I'm not sure if giving each host a
prefix in 2001:'s address space is scalable either for the hosts, the SLAAC
announcements, or just carving up 2001:'s addresses, especially if you have
a large VPN population. I've done that myself, and I have
On Oct 23, 2012, at 01:29 , Ray Bellis ray.bel...@nominet.org.uk wrote:
On 22 Oct 2012, at 19:57, james woodyatt j...@apple.com wrote:
I would say that it MUST be deprecated by the arch document.
The arch document is Informational and contains no RFC 2119 keywords.
My email to the list
On Oct 23, 2012, at 08:20 , Michael Thomas m...@mtcc.com wrote:
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
Can you explain why this behaviour, combined with the prefer matching
interface rule in RFC 3484, is not sufficient? If not, then there is no
problem to solve here.
Your ISP
Op 23 okt. 2012, om 19:28 heeft Michael Thomas het volgende geschreven:
On 10/23/2012 10:25 AM, Teco Boot wrote:
I'm not sure if giving each host a
prefix in 2001:'s address space is scalable either for the hosts, the
SLAAC
announcements, or just carving up 2001:'s addresses,
I agree with Lorenzo Colitti, Ted Lemon, James Woodyatt, and
various others about the adverse operational impacts of using
NPT66.
So I also agree that the Home Net Architecture document (and
any other applicable Home Net documents) ought to clearly
indicate that NPT66 is NOT part of the HomeNet
On Wed, Oct 24, 2012 at 12:20 AM, Michael Thomas m...@mtcc.com wrote:
On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas m...@mtcc.com mailto:
m...@mtcc.com wrote:
No, sorry. Corporate VPN's using v6 and the lack of a coherent source
address
On Wed, Oct 24, 2012 at 2:03 AM, Michael Richardson
mcr+i...@sandelman.cawrote:
That solves the routing problem.
But, what about the naming problem? (whose DNS server do you use?)
NPT66 doesn't solve that either, right?
I believe the DNS problem needs to be solved using split DNS at the
On Oct 22, 2012, at 06:12 , Tim Chown t...@ecs.soton.ac.uk wrote:
Therefore what seems to be on the table for homenet are:
[...]
d) NPT66 (RFC6296), which the homenet arch does not recommend, but see
draft-bonica-v6-multihome-03.
[...]
Why is this option still on the table?
Who is arguing
On Oct 22, 2012, at 1:43 PM, james woodyatt j...@apple.com wrote:
Can we strengthen HOMENET arch to deprecate NPT66 explicitly?
Yes, please.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
On 10/22/12 11:07 AM, Tim Chown wrote:
On 22 Oct 2012, at 18:47, Ted Lemon mel...@fugue.com wrote:
On Oct 22, 2012, at 1:43 PM, james woodyatt j...@apple.com wrote:
Can we strengthen HOMENET arch to deprecate NPT66 explicitly?
Yes, please.
I meant 'on the table' as there is a draft out
On Oct 22, 2012, at 11:28 , mike m...@mtcc.com wrote:
I'd say that until we have source address selection that actually works and
is widely
deployed, that taking anything off the table is premature. Source address
selection
applies just as much on a homenet as anyplace else.
Disagree.
On 10/22/2012 11:57 AM, james woodyatt wrote:
On Oct 22, 2012, at 11:28 , mike m...@mtcc.com wrote:
I'd say that until we have source address selection that actually works and is
widely
deployed, that taking anything off the table is premature. Source address
selection
applies just as much on
Since earlier on this thread someone was asking for consensus: for the
record, I agree with all James's points.
I think that homenet should declare that NPT66 is not a supported means for
multihoming in home networks.
Yes, there is a multihoming problem, but no, NPT66 is not a solution/ NPT66
is
Regarding all the discussion around this document I think a f2f discussion
could help.
Would you please give us a time slot to discuss this during next meeting?
Thank you,
Damien Saucez
On 11 Oct 2012, at 11:37, Tim Chown t...@ecs.soton.ac.uk wrote:
On 1 Oct 2012, at 22:14, Brian E
I have read the draft and don't see how it advances Homenet.
IMHO If an MSP wants to deploy some tunnel brokers on the Internet to
terminate what boils down to a pair of GRE tunnels, they can do so
without the IETF providing any new standards work, and it'll all work
just fine.
I'd prefer
On 01 Oct 2012, at 14:33, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
On 01/10/2012 08:32, Damien Saucez wrote:
Curtis,
Thank you for the comments.
Our target in this document is to raise the question of multihoming
in personal and/or small/medium enterprise networks, so for
Curtis Damien,
On 01/10/2012 19:01, Curtis Villamizar wrote:
In message 50698d7f.5000...@gmail.com
Brian E Carpenter writes:
On 01/10/2012 08:32, Damien Saucez wrote:
Curtis,
Thank you for the comments.
Our target in this document is to raise the question of multihoming
in personal
34 matches
Mail list logo
