Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-23 Thread Iljitsch van Beijnum

On 22 apr 2009, at 23:39, Jack Bates wrote:

What really would help is more people who are not on NANOG pushing  
vendors to support IPv6. Even my Juniper SE has mentioned that I'm  
one of 2 people he's had seriously pushing for IPv6 features. Other  
vendors have just blown me off all together (we'll have it sometime).


Right. And I'm also the only one asking for 32-bit AS numbers.

People who run networks can do a lot: believe it or not, the IETF  
really wants input from network operators, especially in the early  
phases of protocol development when the requirements are established.



Serious input and participation means work and money.


You can participate on mailinglists without attending meetings, so in  
that sense it doesn't have to cost money. As an operator, it would  
make sense to spend a little time in the requirements phase but not  
after that. So yes, it would take time, but we're not talking about  
hours a day on an ongoing basis.


Doesn't help that when I was a wee one, mom dated someone who  
bragged about his status in the IETF


:-)

and even had a pen. Sad way to be introduced to any organization,  
but I have seen similar mentalities regarding IETF mentioned here  
reinforcing my belief that arrogance is alive and I don't have the  
time and money to deal with it.


In any case, if you have input on this whole NAT64 business, let me  
and/or Fred know. If you have input on anything else, speak up on this  
list or a NANOG meeting and there's a decent chance that someone will  
take those comments back to the IETF.




Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-23 Thread Iljitsch van Beijnum

On 23 apr 2009, at 12:23, Nathan Ward wrote:

Just participating in mailing lists is good for keeping up to date,  
but not so good for getting things changed.



That's what I've found, anyway. Might not always be true.


Depends on the issue. Sometimes bad ideas get traction in the IETF,  
it's hard to undo that. But there are also times when even a single  
message containing good arguments can have an effect.


Also don't expect too much from IETF participation: if doing X is  
going to make a vendor more money than doing Y, they're going to favor  
X, even if Y is the superior solution.




Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-23 Thread William Allen Simpson

Iljitsch van Beijnum wrote:
Depends on the issue. Sometimes bad ideas get traction in the IETF, it's 
hard to undo that. 



That's an understatement.


Also don't expect too much from IETF participation: if doing X is going 
to make a vendor more money than doing Y, they're going to favor X, even 
if Y is the superior solution.



Some wag around here re-christened it the IVTF (V stands for Vendor, not
Victory). ;-)  I haven't bothered to go in years



Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-23 Thread Pekka Savola

On Thu, 23 Apr 2009, Nathan Ward wrote:
After trying to participate on mailing lists for about 2 or 3 years, it's 
pretty hard to get anything done without going to meetings.


Just participating in mailing lists is good for keeping up to date, but not 
so good for getting things changed.


That's what I've found, anyway. Might not always be true.


If you were to go to meetings, you would realize that it won't help in 
gettings things changed significantly better than active mailing 
list participation would... :-/


--
Pekka Savola You each name yourselves king, yet the
Netcore Oykingdom bleeds.
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-23 Thread Adrian Chadd
On Thu, Apr 23, 2009, William Allen Simpson wrote:

 Some wag around here re-christened it the IVTF (V stands for Vendor, not
 Victory). ;-)  I haven't bothered to go in years

If the people with operational experience stop going, you can't blame the group 
for
being full of vendors.

Methinks its time a large cabal of network operators should represent
at IETF and make their opinions heard as a collective group.
That would be how change is brought about in a participative organisation,
no? :)



Adrian




Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-23 Thread bmanning
On Thu, Apr 23, 2009 at 08:17:07PM +0800, Adrian Chadd wrote:
 On Thu, Apr 23, 2009, William Allen Simpson wrote:
 
  Some wag around here re-christened it the IVTF (V stands for Vendor, not
  Victory). ;-)  I haven't bothered to go in years
 
 If the people with operational experience stop going, you can't blame the 
 group for
 being full of vendors.
 
 Methinks its time a large cabal of network operators should represent
 at IETF and make their opinions heard as a collective group.
 That would be how change is brought about in a participative organisation,
 no? :)
 
 Adrian

Operator participation in IETF has been a problem for at least
18 years.  I remember a fairly large dustup w/ John Curran and 
Scott Bradner over why the OPS area was so lacking in actual 
operators at the Columbus IETF.  Its never gotten any better.

IETF used to be populated by developers and visionaries (grad students
with lofty ideas).   Once commercialization set in (they graduated
and got jobs)  their  funding sources changed from government grants
to salaries.   And management took a more active role.  the outcome
is that vendors now control much of the IETF participation and 
indirectly
control IETF output.

just my 0.02 from the cheap seats.

--bill



Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-23 Thread Nathan Ward

On 24/04/2009, at 12:14 AM, Pekka Savola wrote:

On Thu, 23 Apr 2009, Nathan Ward wrote:
After trying to participate on mailing lists for about 2 or 3  
years, it's pretty hard to get anything done without going to  
meetings.


Just participating in mailing lists is good for keeping up to date,  
but not so good for getting things changed.


That's what I've found, anyway. Might not always be true.


If you were to go to meetings, you would realize that it won't help  
in gettings things changed significantly better than active  
mailing list participation would... :-/


I got heaps done in SFO - to the point where I'm happy to pay to get  
to Stockholm and Hiroshima later this year (I'm self employed, and  
live at the end of the world, so for me it's harder than most who just  
have to convince the boss :-).


--
Nathan Ward




Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-23 Thread Iljitsch van Beijnum

On 23 apr 2009, at 14:17, Adrian Chadd wrote:


Methinks its time a large cabal of network operators should represent
at IETF and make their opinions heard as a collective group.
That would be how change is brought about in a participative  
organisation,

no? :)


Why don't you start by simpling stating what you want to have happen?

So far I've seen a number of messages complaining about the IETF (btw,  
if you like complaining about the IETF, go to the meetings, there is  
significant time set aside for that there) but not a single technical  
request, remark or observation.


The IETF works by rough consensus. That means if people disagree,  
nothing much happens. That is annoying. But a lot of good work gets  
done when people agree, and a lot of the time good technical arguments  
help.


Like I said, the IETF really wants input from operators. Why not start  
by giving some?




NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-22 Thread Iljitsch van Beijnum

On 22 apr 2009, at 0:19, Owen DeLong wrote:

B) Again, while it might be the IETF's job, shouldn't the group  
trusted with the management of the IP space at least have a public  
opinion about these solutions are designed. Ensuring that they are  
designed is such a way to guarantee maximum adoption of v6 and thus  
reducing the potential for depletion of v4 space.


The IETF specifically does not accept organizational input and  
requires instead that individuals participate.


So how is the RIR model where you become a member and then participate  
better? If ARIN or the other RIRs have compelling arguments the only  
reason those arguments are compelling is because of their merit, not  
because they're from a RIR.



it means that even if ARIN could develop a public
opinion (which would have to come from the ARIN community by some  
process which
we don't really have as yet), this opinion wouldn't mean much in the  
IETF's eyes.


Well, if you, ARIN, or anyone else has input that should be considered  
when writing with a better specification for an IPv6-IPv4 translator,  
please let us know.


For the past year or so the IETF behave working group has been  
considering the issue, and looked at a whole bunch of scenarios: from  
a small IPv6 network to the public IPv4 internet, to private IPv4  
addresses, from a small IPv4 network to the public IPv6 internet, to  
(not entirely) private IPv6 addresses. The IPv6-IPv4 case seems  
doable with a bunch of caveats (it's still NAT) and we (for some value  
of we) want to get it out fast, but the other way around looks much  
more difficult and will at the very least take longer.


The softwire(s?) working group is looking at tunneling IPv4 over IPv6  
towards a big carrier grade NAT so IPv4 hosts/applications can still  
work across an IPv6 access network with only one layer of NAT.


In v6ops CPE requirements are being discussed so in the future, it  
should be possible to buy a $50 home router and hook it up to your  
broadband service or get a cable/DSL modem from your provider and the  
IPv6 will be routed without requiring backflips from the user.


So there is a fair chance that we'll be in good shape for IPv6  
deployment before we've used up the remaining 893 million IPv4  
addresses.




Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-22 Thread Jack Bates

Iljitsch van Beijnum wrote:
In v6ops CPE requirements are being discussed so in the future, it 
should be possible to buy a $50 home router and hook it up to your 
broadband service or get a cable/DSL modem from your provider and the 
IPv6 will be routed without requiring backflips from the user.


So there is a fair chance that we'll be in good shape for IPv6 
deployment before we've used up the remaining 893 million IPv4 addresses.


I think this annoys people more than anything. We're how many years into 
the development and deployment cycle of IPv6? What development cycle is 
expected out of these CPE devices after a spec is FINALLY published?


If the IETF is talking future and developers are also talking 
future, us little guys that design, build, and maintain the networks 
can't really do much. I so hope that vendors get sick of it and just 
make up their own proprietary methods of doing things. Let the IETF 
catch up later on.



/RANT

Jack



Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-22 Thread Iljitsch van Beijnum

On 22 apr 2009, at 22:12, Jack Bates wrote:

I think this annoys people more than anything. We're how many years  
into the development and deployment cycle of IPv6? What development  
cycle is expected out of these CPE devices after a spec is FINALLY  
published?


That's certainly one way to look at this, and I'm just as unhappy  
about how long this has taken as you. On the other hand, it has been  
argued that these issues are outside the scope of the IETF in the  
first place, as it's just application of already established  
protocols, not developing something new. So another way to look at it  
is that at least the IETF is finally doing something because so far,  
nobody else has. What would have helped here is more push in this  
direction.


If the IETF is talking future and developers are also talking  
future, us little guys that design, build, and maintain the  
networks can't really do much. I so hope that vendors get sick of it  
and just make up their own proprietary methods of doing things. Let  
the IETF catch up later on.


People who run networks can do a lot: believe it or not, the IETF  
really wants input from network operators, especially in the early  
phases of protocol development when the requirements are established.


Proprietary methods duking it out in the market place is nice for  
stuff that happens inside one box or at least within one  
administrative domain, but it would be a nightmare in broadband  
deployment where I want my Windows box to talk to my Apple wifi base  
station and my Motorola cable modem to the ISP's Cisco headend and  
their Extreme switches and Juniper routers.





Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-22 Thread Ren Provo
Ron Bonica is leading a BOF during NANOG46 in Philly which may be of interest -

BOF: IETF OPS  MGMT Area,
Ron Bonica, Juniper Networks
Presentation Date: June 14, 2009, 2:00 PM - 3:30 PM

Abstract:
The IETF OPS  MGMT Area documents management technologies and
operational best common practices. The purpose of this BoF is to
review activities in that area and solicit feedback to determine the
usefulness of those activities to the operator community. We will also
solicit proposals for new work that is of interest to users.

The full agenda is up at - http://www.nanog.org/meetings/nanog46/agenda.php
Cheers, -ren


On Wed, Apr 22, 2009 at 5:18 PM, Iljitsch van Beijnum
iljit...@muada.com wrote:

 On 22 apr 2009, at 22:12, Jack Bates wrote:

 I think this annoys people more than anything. We're how many years into the 
 development and deployment cycle of IPv6? What development cycle is expected 
 out of these CPE devices after a spec is FINALLY published?

 That's certainly one way to look at this, and I'm just as unhappy about how 
 long this has taken as you. On the other hand, it has been argued that these 
 issues are outside the scope of the IETF in the first place, as it's just 
 application of already established protocols, not developing something new. 
 So another way to look at it is that at least the IETF is finally doing 
 something because so far, nobody else has. What would have helped here is 
 more push in this direction.

 If the IETF is talking future and developers are also talking future, us 
 little guys that design, build, and maintain the networks can't really do 
 much. I so hope that vendors get sick of it and just make up their own 
 proprietary methods of doing things. Let the IETF catch up later on.

 People who run networks can do a lot: believe it or not, the IETF really 
 wants input from network operators, especially in the early phases of 
 protocol development when the requirements are established.

 Proprietary methods duking it out in the market place is nice for stuff that 
 happens inside one box or at least within one administrative domain, but it 
 would be a nightmare in broadband deployment where I want my Windows box to 
 talk to my Apple wifi base station and my Motorola cable modem to the ISP's 
 Cisco headend and their Extreme switches and Juniper routers.





Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-22 Thread Jack Bates

Iljitsch van Beijnum wrote:

What would have helped here is more push in this direction.



What really would help is more people who are not on NANOG pushing 
vendors to support IPv6. Even my Juniper SE has mentioned that I'm one 
of 2 people he's had seriously pushing for IPv6 features. Other vendors 
have just blown me off all together (we'll have it sometime).


People who run networks can do a lot: believe it or not, the IETF really 
wants input from network operators, especially in the early phases of 
protocol development when the requirements are established.




Serious input and participation means work and money. Too much for me. 
Doesn't help that when I was a wee one, mom dated someone who bragged 
about his status in the IETF and even had a pen. Sad way to be 
introduced to any organization, but I have seen similar mentalities 
regarding IETF mentioned here reinforcing my belief that arrogance is 
alive and I don't have the time and money to deal with it.


Proprietary methods duking it out in the market place is nice for stuff 
that happens inside one box or at least within one administrative 
domain, but it would be a nightmare in broadband deployment where I want 
my Windows box to talk to my Apple wifi base station and my Motorola 
cable modem to the ISP's Cisco headend and their Extreme switches and 
Juniper routers.


Sure, but the largest missing pieces for IPv6 are single box 
implementations. Proprietary NAT is single box. Will it break stuff? 
Probably, but when hasn't it? Corporate networks won't care. They'll 
deploy the vendor that supports it if that is what they want. 
BRAS/Aggregation is another single box solution but defines everything 
about an edge broadband network, supported by the access devices 
(switches, dslams, wireless ap/backhauls, etc). The layer 3 aware access 
devices all tend to have their own single box methods of security (DHCP 
snooping, broadcast scoping, etc, etc). I've seen quite a few systems 
that can't turn the security support off and break IPv6 because of it.



Jack




Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-22 Thread Nathan Ward

On 23/04/2009, at 8:12 AM, Jack Bates wrote:


Iljitsch van Beijnum wrote:
In v6ops CPE requirements are being discussed so in the future, it  
should be possible to buy a $50 home router and hook it up to your  
broadband service or get a cable/DSL modem from your provider and  
the IPv6 will be routed without requiring backflips from the user.
So there is a fair chance that we'll be in good shape for IPv6  
deployment before we've used up the remaining 893 million IPv4  
addresses.


I think this annoys people more than anything. We're how many years  
into the development and deployment cycle of IPv6? What development  
cycle is expected out of these CPE devices after a spec is FINALLY  
published?


If the IETF is talking future and developers are also talking  
future, us little guys that design, build, and maintain the  
networks can't really do much. I so hope that vendors get sick of it  
and just make up their own proprietary methods of doing things. Let  
the IETF catch up later on.



This work is actually mostly being done by some guys at Cisco, and  
other vendors have plenty of input as well.


I would be surprised if CPEs that support the outcome of this work are  
far behind the RFC being published (or even a late draft).


--
Nathan Ward




Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]

2009-04-22 Thread Joel Jaeggli


Jack Bates wrote:
 Iljitsch van Beijnum wrote:
 In v6ops CPE requirements are being discussed so in the future, it
 should be possible to buy a $50 home router and hook it up to your
 broadband service or get a cable/DSL modem from your provider and the
 IPv6 will be routed without requiring backflips from the user.

 So there is a fair chance that we'll be in good shape for IPv6
 deployment before we've used up the remaining 893 million IPv4 addresses.
 
 I think this annoys people more than anything. We're how many years into
 the development and deployment cycle of IPv6? What development cycle is
 expected out of these CPE devices after a spec is FINALLY published?

ipv6 cpe devices have been / are being developed already. the doesn't
mean there isn't more work to be done, in

 If the IETF is talking future and developers are also talking
 future, us little guys that design, build, and maintain the networks
 can't really do much. I so hope that vendors get sick of it and just
 make up their own proprietary methods of doing things. Let the IETF
 catch up later on.

Generally the presumption is that people bring work that they are
working on to the table. I work for an equipment vendor, if there's no
reason for us to implement something why would would we expend cycles to
work on it in the IETF either?

 
 /RANT
 
 Jack