Re: ISP port blocking practice

[Valdis . Kletnieks]

On Thu, 22 Oct 2009 22:36:13 EDT, Jon Kibler said:

>4) Never allow traffic to ingress any network if the source address is 
> bogus.

4a) Never flag a source address as bogus unless you can verify it is bogus
*today*, not when you installed the filter.  Out of date bogon filters are evil.



pgpwJHR922JEm.pgp
Description: PGP signature

Re: ISP port blocking practice

[Steve Bertrand]

Jon Kibler wrote:
> Zhiyun Qian wrote:
>> Hi all,
> 
>> What is the common practice for enforcing port blocking policy (or what
>> is the common practice for you and your ISP)? More specifically, when
>> ISPs try to block certain outgoing port (port 25 for instance), they
>> could do two rules:
>> 1). For any outgoing traffic, if the destination port is 25, then drop
>> the packets.
>> 2). For any incoming traffic, if the source port is 25, then drop the
>> packets.
> 
>> Note that either of the rule would be able to block outgoing port 25
>> traffic since each rule essentially represent one direction in a TCP
>> flow. Of course, they could apply both rules. However, based on our
>> measurement study, it looks like most of the ISPs are only using rule
>> 1). Is there any particular reason why rule 1) instead of rule 2)? Or
>> maybe both?
> 
>> Also, is it common that the rules are based on tcp flags (e.g. SYN,
>> SYN-ACK)? One would think block SYN packet is good enough.
> 
>> Regards.
>> -Zhiyun
> 
> I understand your question, and I believe that you have been given a lot of 
> good
> answers. However, I believe that, as an ISP, you are asking the wrong 
> question;
> more precisely, you are only asking part of the real question you should be
> asking. The more appropriate question should be: "What should be our network
> filtering policies?"
> 
> To answer that question, I would start with ingress and egress filtering by IP
> address, protocol, etc.:
>1) Never allow traffic to egress any subnet unless its source IP address is
> within that subnet range.

Sorry to nit, but shouldn't your uRPF setup take care of this (and many
other of your list items), long before ACL?

It's absolutely great if you have your list implemented, but imho, all
ISP's, no matter how small should investigate and implement urpf. It's
especially fun to play with RTBH.

To be honest, the smaller you are, the easier it is to implement (ie.
urpf strict everywhere!  :)

Steve

RE: IPv6 Deployment for the LAN ... anycast

[TJ]

> >> WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?
> > You want to allow for more than one for obvious fault isolation and
> > load balancing reasons.  The draft suggested using :::1

FWIW - I think simple anycast fits that bill.


> > I personally would suggest getting a well known ULA-C allocation
> > assigned to IANA, then use :::1
> > :::2 and :: > assignment>:3, where  could be "0035" for DNS,
> > and "007b" for NTP, and if you're feeling adventurous you could use
> > "0019" for outgoing SMTP relay.

IMHO non-hex-converted port numbers works cleanly ... ?


> I thought ULA-C was dead... Did someone resurrect this unfortunate bad
> idea?

Anything is dead until someone uses it.
I was thinking FD00 just to have symmetry with anyone using ULAs today, so
FC00::/8 could be outright blocked ... ?
FC may make sense as they are, de facto, registered ...


> >> ... Heck, start a registry (@IANA) and add in FD00::101, etc. ...
> >> Maybe reserve FD00::/96 for this type of "ULA port-based anycast
> >> allocation". (16bits would only reach  w/o hex-conversion (if
> >> hex-converted could reserve FD00::/112 ... But would be less
> >> obvious))

Thinking further, if simply based on port#s wouldn't even need a registry.
Unless it was decided to implement the multiple-addresses-per-function
mentioned above, then perhaps useful.


> >> Easily identified, not globally routable, can be pre-programmed in
> >> implementations/applications ... ?
> > Exactly, seems easy, straight forward, robust, reliable and allows
> > for things like fate sharing and fail over.
> Why pull this out of ULA?  Why not pull it out of /16 or one of
> the other reserved prefixes?

ULAs are already defined as "internally routable, but not globally routable"
- which is exactly how I would envision these being used.
IOW, seemed to make sense to me!


/TJ

Re: IPv6 Deployment for the LAN

[Owen DeLong]

On Oct 22, 2009, at 5:00 PM, Perry Lorier wrote:


trej...@gmail.com wrote:

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53?

You want to allow for more than one for obvious fault isolation and  
load balancing reasons.  The draft suggested using :::1  
I personally would suggest getting a well known ULA-C allocation  
assigned to IANA, then use :::1  
:::2 and ::assignment>:3, where  could be "0035" for DNS,  
and "007b" for NTP, and if you're feeling adventurous you could use  
"0019" for outgoing SMTP relay.


I thought ULA-C was dead... Did someone resurrect this unfortunate bad  
idea?





... Heck, start a registry (@IANA) and add in FD00::101, etc. ...  
Maybe reserve FD00::/96 for this type of "ULA port-based anycast  
allocation". (16bits would only reach  w/o hex-conversion (if  
hex-converted could reserve FD00::/112 ... But would be less  
obvious))



Easily identified, not globally routable, can be pre-programmed in  
implementations/applications ... ?





Exactly, seems easy, straight forward, robust, reliable and allows  
for things like fate sharing and fail over.


Why pull this out of ULA?  Why not pull it out of /16 or one of  
the other reserved prefixes?


Owen

Re: IPv6 Deployment for the LAN

[Owen DeLong]

On Oct 22, 2009, at 4:27 PM, Joe Maimon wrote:




Ray Soucy wrote:


Others may have their specific requests from vendors, but here are  
mine:
1. Include DHCPv6 client functionality as part of any IPv6  
implementation.

2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure.


I can agree with that.

I would also add that there is plenty of work that can be done to  
DHCP, such as adding full route support, multiple gateways with  
preference and even transitioning from a binary only protocol.



A lot of the frustration seems to come from Windows ICS acting as an
IPv6 router.  I think everyone here has been after Microsoft to  
either

remove ICS or make it more difficult to enable at one point or
another.  While a rogue RA can come from anywhere, Windows is usually
the guilty party.  I would argue that since NAT is not a component of
IPv6,


NAT wasnt a component of IPv4 until it was already had widespread  
adoption. I remain completely unconvinced that people will not  
continue to perceive value in PAT6 between their private and their  
public subnets.


People may perceive value, but, I truly hope that they won't be able  
to obtain the "functionality".  It's just a very bad idea that does  
terrible things to the network. NAT/PAT was a necessary evil in IPv4  
to extend the lifetime of the addressing until IPv6 could be almost  
ready. It should be allowed to die with IPv4.


And of course, different forms of NAT are almost certainly required  
to try to make ipv4 and ipv6 interoperate for as long as people need  
it to.



Sort of, but, yeah.  That's OK.  Unfortunate, but, OK.

I actually think that now that we have a transfer market policy, IPv4  
will probably die much faster than it would have otherwise.


Owen

Re: ISP port blocking practice

[Owen DeLong]

On Oct 22, 2009, at 4:14 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:


Few
companies use the MSP port (tcp/587).


Can you elaborate. Is this based on analysis you've conducted on
your own network? And if so, is the data (anonymized) available for
the rest of us to look at?

My experience is that port 587 isn't used because ISPs block it
out-of-hand.  Or in the case of Rogers in (at least) Vancouver, hijack
it with a proxy that filters out the AUTH parts of the EHLO response,
making the whole point of using the submission service ...  pointless.

--lyndon

Wow... That's evil.  Most ISPs I've dealt with don't have that  
problem, but,

if I encountered one that did, I'd vote with my feet in short order.

Owen

Re: IPv6 Deployment for the LAN

[Owen DeLong]

On Oct 22, 2009, at 4:12 PM, Karl Auer wrote:


On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote:
If, on the other hand, the REAL desire is to have a DHCP server  
break
the tie in the selection between several routers that advertise  
their

presence, that wouldn't be unreasonable.


In some configurations not all hosts are supposed to use the same
router.  We need the _option_ to specify a default gateway and
have the override any RA's a host may see.


It would be a tool, and if someone wants to use a tool, they can. It
won't be my thumb they hit :-)

But I can't see how a DHCP server can know enough about the routers to
be able to send out useful discrimination information. So it will have
to be manually entered, or come from an IPAM, or...

Current practice in the environments I know that are doing this is  
that groups

of hosts are maintained in a database (including MAC addresses) and
this database is used to build the DHCP configuration.  The host group
is assigned a default router address which is actually a VRRP group  
address.


The routers then elect an appropriate VRRP active/standby  
configuration and

the hosts route via the Active router for their VRRP group.  If the host
administrators find that a host needs to be part of a different VRRP  
group
for whatever reason, there are tools at their disposal to address that  
issue.

DHCP lease times can be short since the addresses are actually static
anyway (yes, lots of people use DHCP to assign static addresses in
production environments because it allows table-driven central  
management

of host assignment).


Nor can I see how the DHCP server can identify the routers to the host
except by their addresses, and these can change or be removed without
the DHCP server finding out.


In most environments I know, there are addresses reserved for the VRRP
groups that the routers participate in and the router administrators are
well aware of the damage they will bring if they change them without
extensive planning and notice.


The only way I can see it working is if the host were smart enough to
compare the DHCP router discrimination info with the information it  
has
received via RA and delete mismatches, or possibly just revert to  
using

RA information if any mismatches at all are detected. That would be an
item the DHCP server could specify as well - what to do in case of a
mismatch. It could even be specified on a per-router basis, though the
whole thing seems to be getting a bit unwieldy now.


That would be a terrible choice because you have eliminated one of the
key reasons that some installations need DHCP to assign router  
information

instead of RA.  While what you propose is probably technically cleaner
from a pure protocol design perspective, the reality is that pure  
protocol

design is not how the real world thinks or operates.  In the real world,
one must make the protocol adapt to the business rules and other
odd parameters that don't always make logical sense from a protocol
design perspective. This is one such example when you have different
administrative groups responsible for hosts and routers.

I know it is rare to find an enterprise where the network
infrastructure is not run by the same group that does the systems
administration.

But in many of these organizations, this means that having the
router specify the default gateway to the host is not going to work
well for the systems administrators. In today's world, they don't
have to worry about this and, the network group, surprisingly,
is pretty good at keeping the VRRP groups numbered as they
are supposed to be (usually .1, .2, etc. or .254, .253, .252, etc.,
or whatever the first/last addresses of a segment happen
to be).


The DHCP servers will not be on the same subnets as all the routers
involved, so they can't sniff the RAs themselves - unless we set up an
RA relay... hmm.


They don't need to.


I don't see DHCP-delivered router preferences as being something that
will "break the Internet". In the vast majority of cases they will be
unnecessary. For those that do need it though, and if it can be done,
why not?

Why do router preferences instead of just routers?  Sure, the DHCP  
server

doesn't know which router should be doing the routing, but, VRRP can
take care of that as it does today.  The DHCP server just needs to  
assign

the VRRP group.

Owen
\

Re: ISP port blocking practice

[Owen DeLong]

On Oct 22, 2009, at 3:39 PM, Justin Shore wrote:


Zhiyun Qian wrote:

Hi all,
What is the common practice for enforcing port blocking policy (or  
what is the common practice for you and your ISP)? More  
specifically, when ISPs try to block certain outgoing port (port 25  
for instance), they could do two rules:
1). For any outgoing traffic, if the destination port is 25, then  
drop the packets.
2). For any incoming traffic, if the source port is 25, then drop  
the packets.


I block on both generally.  I block inbound and outbound for  
residential customers in dynamic pools.  I block inbound only for  
residential with statically-assigned IPs.  That way a customer can  
request (and pay for) a static IP and be able to get around out  
outbound SMTP block.  Few companies use the MSP port (tcp/587).  I'm  
not sure why more don't make the effort but most don't.  To make up  
for that we allow static residential customers to evade that filter  
with a static IP.  We still block inbound though.  We also allow  
them to use our SMTP servers and SmartHosts if they want with no  
requirements on source domains (like some providers require,  
essentially requiring the customer to advertise for you).  The  
inbound block isn't really all that useful as you elude to.  However  
I use it more often than not to look for people scanning out ranges  
for open relays.  I use that data for feed my RTBH trigger router  
and drop the spammer's traffic on the floor (or the poor,  
unfortunate owner of the compromised PC that's been 0wned.



Blocking ports that the end user has not asked for is bad.

Doing it and refusing to unblock is worse.

Some ISPs have the even worse practice of blocking 587 and a few even
go to the horrible length to block 465.

A few hotel gateways I have encountered are dumb enough to think they  
can block TCP/53

which is always fun.

We block several other things too.  Netbios traffic gets dropped  
both ways.  MS-SQL traffic gets dropped both ways (a few users have  
complained about this but very few stick to their guns when you  
point out that their traffic is traversing the web completely  
unencrypted).  I block default and common proxy ports such as 3128,  
7212, and 6588 in both directions.  Squid is too easy to  
misconfigure (done it myself). GhostSurf and WinGate have both been  
abusable as open proxies in various releases.  I also block 8000,  
8080 and 8081 towards the customers. These are some of our most  
commonly scanned ports (usually all 3 at once plus some or all of  
the 80xx ones).  I've encountered many compromised residential CPEs  
that the users either enabled themselves or were enabled by  
default.  I don't block those 3 ports on outbound flows though; too  
many false positives.


And finally we also block several different types of ICMPs.  First  
off we block ICMP fragments.  Then we permit echo, echo-reply,  
packet-too-big, and time-exceeded.  The rest get explicitly dropped.  
IPv6 will change this list dramatically.  I haven't had time to  
research ICMPv6 thoroughly enough to say any more than that.


Basically I just pick out some of the really bad ports and block  
them. This gives me a wealth of data with which to null-route  
compromised PCs scanning my networks.


Lovely for you, but, not particularly helpful to your customers who  
may actually want to use some of those services.


Owen

Re: ISP port blocking practice

[Steve Bertrand]

Sean Donelan wrote:
> On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
>> My experience is that port 587 isn't used because ISPs block it
>> out-of-hand.  Or in the case of Rogers in (at least) Vancouver, hijack
>> it with a proxy that filters out the AUTH parts of the EHLO response,
>> making the whole point of using the submission service ...  pointless.
> 
> You mentioned this last June.  Can anyone else corroborate it?  Rogers
> says they don't do that, and lots of other people seem to be able to
> use port 587 on Rogers (and other ISPs) without problems.
> 
> All the cases I've looked at, where someone claimed an ISP was blocking
> port 587, it turned out to be some other problem.  The most common
> reason was related to some security software/host based firewall running
> on the user's own computer.

Please pardon my ignorance here, especially if I've mistaken context...

Although I'm not an email engineer, it was at *least* three-1/2 years
ago that we switched our users from sending on port 25, to auth over 587
('users' meaning the clients we have as an ISP/hosting company, which
can establish on 587 from within OR without our network).

Although I can recall a few edge cases that were brought to my attention
for clients (users) not able to submit from a different network, the
collateral damage has been ~1%. (ironically however, it seems as though
recently those who have gone with a 'stick' have been reporting issues,
and we've had to have them switch to port 25 on the SMTP server within
the relevant network).

I never even imagined that someone would do port 587 blocking as such.

I'll have to light up on the network of the next client that complains,
and if 587 doesn't get through, I'll start advising the helpdesk that
they should redirect the former-client to call the 'ISP'.

Someone please tell me that I'm misunderstanding something, so that I
don't feel that two years of client notices, research and
implementation, and another two years of dealing with manual support
calls because they didn't 'see' the 400 warnings of email changes wasn't
all a waste.

fwiw to keep on topic, I block all 25-in with a small exception list for
a few colo boxes, and our incoming MTA collection/filtering cluster.

This 'in' ACL is placed on all PE hardware. The incoming mail cluster is
attached to it's own PE, which ensures that everything from anywhere on
the network eventually filters through this ACL, and that the core is
always essentially clean.

I then pretty much do the same out-25 on all PE hardware. Because my
network is small, I manually/strictly manage the ACLs on any PE that is
Internet/Peer facing.

colo servers that require SMTP services is either connected to a PE
designed to allow it, or is put into a VLAN designed for such. afair, I
have only two clients remaining that I haven't forced into a /29 corner
where I can SWIP their space, thereby using the 'you're responsible'
hammer. Either way, even without the swip, I've made them well aware of
the repercussions of failing to at least be attentive.

Steve

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Owen DeLong]

On Oct 22, 2009, at 2:31 PM, TJ wrote:




Then let me say it. RA needs to be able to be completely turned  
off.

DHCPv6 needs to be able to completely configure all requesting hosts.



Those two statements are not synonymous ...

They may not be synonymous, but, there is a set of operators for whom  
both

are true.



Sure, leave RA in the IPv6 stack. The market will decide, and we  
will see if

it is still on by default on soho routers and in IOS 15.4T in 2015.

That is a more sensible statement.  And were I to be a gambling man  
I would
say it will indeed be on by default ... we'll talk more about it  
then :).



Also, I would like to add - there is a difference between the default
gateway information and other things, such as NTP|DNS|SIP server
information.


Maybe.

The default gateway, by definition, is an on-link thing.  IMHO, this  
makes

the router a good source for information about the router.


It does in some cases.  In other cases, it does not.

I am not saying use cases for "fully spec'ed DHCPv6" don't exist or  
should

be ignored.
Making the router capable of sharing the "missing piece" that covers  
~95% of

use cases is also a Good Thing.

I don't think most people are arguing that it should not be possible  
to configure
a network for RA/SLAAC with the RA providing the gateway information.   
In fact,
I think most of us would like to see RA/SLAAC capable of providing the  
other

needed pieces of the puzzle.

That said, there is a group of operators for whom RA is a bad thing,  
SLAAC is

also a bad thing, and, their current usage of DHCPv4 does not map to any
existing IPv6 technology, so, they are crying foul and want their  
needs addressed.
I think that is 100% legitimate, regardless of whether Iljitsch thinks  
we are old

enough to play with power tools or not.

Thinking out loud, we could also re-create the idea of an auto-magic  
DNS by
creating a special use case within ULA-space - say FD00::/96, saving  
the

last 32 bits for something like ::53 and using anycast.


That's a fine solution for part of the problem space, but, moving the  
router
assignment function for hosts to a device controlled by the host  
administrator
is a necessary administrative boundary issue for a number of  
organizations.



*(Could abstract same idea to any stateless and/or light-session-based
service ... FD00::123 for Automagic ULA-based anycast NTP, etc.   
Need 32
bits if we don't want to hex convert the > things, just in  
case ...)*


NOOO... If you're going to do fd00:: for this, the 123 case really  
should

be fd00::7b, not fd00::123

Owen

Re: ISP port blocking practice

[Justin Shore]

Joe Maimon wrote:
You can configure exchange to use additional smtp virtual servers and 
bind them to specific ports. You can also require authentication to 
access the ports and you can restrict it to users. You can also enable 
it for STARTTLS.


That I did not know.  Last time I'd looked there wasn't a decent work 
around unless you wanted to run a 2nd Exchange server in a cluster of 
sorts on a 2nd box and change it's default port to 587.  Then let 
Exchange clustering move the mail around on the back end.  This is good 
to know.


I have many a time recommended consulting customers to follow up with 
their mail provider to see if they has any plans to support the rfc 
standard, but I dont share much enthusiasm for complete adoption. I do 
believe it is getting better.


I'm sorry to say that the larger SP that we outsourced our customer mail 
service to doesn't support MSP.  They don't support much of anything 
outside of the very basics.  They require SMTP AUTH but until relatively 
recently they didn't support any AUTH options other than plaintext (I 
was actually shocked just now when I doublechecked because I have looked 
before).  No, I'm not kidding.  They do rDNS checks on every IP list in 
a Received line.  The also do DNSBL DUL checks on all IPs on the 
Received lines (dumb because of course the first one will match if the 
SP has their customer dynamic pools listed in a DUL-type list).  Things 
will change on their end and the way we find out is because of user 
complaints.  The decision to switch to them wasn't a technical one I'm 
afraid.  If you're an Internet *Service* Provider you should probably 
provide you own services.


Justin

Re: ISP port blocking practice

[Jon Kibler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Zhiyun Qian wrote:
> Hi all,
> 
> What is the common practice for enforcing port blocking policy (or what
> is the common practice for you and your ISP)? More specifically, when
> ISPs try to block certain outgoing port (port 25 for instance), they
> could do two rules:
> 1). For any outgoing traffic, if the destination port is 25, then drop
> the packets.
> 2). For any incoming traffic, if the source port is 25, then drop the
> packets.
> 
> Note that either of the rule would be able to block outgoing port 25
> traffic since each rule essentially represent one direction in a TCP
> flow. Of course, they could apply both rules. However, based on our
> measurement study, it looks like most of the ISPs are only using rule
> 1). Is there any particular reason why rule 1) instead of rule 2)? Or
> maybe both?
> 
> Also, is it common that the rules are based on tcp flags (e.g. SYN,
> SYN-ACK)? One would think block SYN packet is good enough.
> 
> Regards.
> -Zhiyun

I understand your question, and I believe that you have been given a lot of good
answers. However, I believe that, as an ISP, you are asking the wrong question;
more precisely, you are only asking part of the real question you should be
asking. The more appropriate question should be: "What should be our network
filtering policies?"

To answer that question, I would start with ingress and egress filtering by IP
address, protocol, etc.:
   1) Never allow traffic to egress any subnet unless its source IP address is
within that subnet range.
   2) Never allow traffic to egress any subnet, if that traffic claims to
originate from the subnet's network number or broadcast address.
   3) Never allow traffic to ingress any subnet, if that traffic is directed to
the subnet's network number or broadcast address.
   4) Never allow traffic to ingress any network if the source address is bogus.
   5) Never allow traffic to ingress or egress any network if it has an protocol
not "supported" by your network (e.g., allow only TCP, UDP, ICMP, ESP, AH, GRE,
etc.).
   6) Never allow traffic to ingress or egress any network if it has an invalid
TCP flags configuration.

These are the rules I can think of off the top of my head without looking at an
actual hardened router. I am sure I am missing some, but these are a good start.

My $0.02 worth.

Jon
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
o: 843-849-8214
c: 843-813-2924
s: 843-564-4224
s: JonRKibler
e: jon.kib...@aset.com
e: jon.r.kib...@gmail.com
http://www.linkedin.com/in/jonrkibler

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrhFp0ACgkQUVxQRc85QlOYlgCggttgagm2sb90Vg7ntEreFtLr
ydAAnjG4zEmkTmLuZpWUey9nNRHZiTLs
=VDEG
-END PGP SIGNATURE-




==
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.

Re: ISP port blocking practice

[Scott Howard]

On Thu, Oct 22, 2009 at 6:29 PM, Justin Shore wrote:

> I can also speak from experience from the enterprise customers of the
> consulting side of my SP that I worked with before returning to the SP.  Not
> a one of them made use of the MSP port.  The vast majority, I'm sorry to
> say, used Microsoft Exchange which to the best of my knowledge doesn't
> support RFC2476.  I did a little Googling just now and couldn't find any
> hits to say they did either.  Some utilized RPC-over-HTTP. Most at the time
> didn't, requiring direct SMTP access or VPN.
>

Depends what you mean by "support RFC2476".

Exchange most definitely supports message submission on port 587.  Whether
it supports RFC2476 to the letter in terms of other requirements I don't
know, but submission as a "client access" mechanism is fully supported, with
all the usual defaults you'd expect (eg, auth required)

Of course, that doesn't mean that it'll be enabled in a specific
environment, or even if it is enabled, that it will be exposed from the
firewall.  Most larger corporates will be using Outlook with Exchange, and
thus may only support RPC-over-HTTP as you've stated.

  Scott

Re: ISP port blocking practice

[Joe Maimon]

Justin Shore wrote:
 The vast majority, I'm 
sorry to say, used Microsoft Exchange which to the best of my knowledge 
doesn't support RFC2476.  


You can configure exchange to use additional smtp virtual servers and 
bind them to specific ports. You can also require authentication to 
access the ports and you can restrict it to users. You can also enable 
it for STARTTLS.


What I dont know is whether Exchange has or ever will support SMTPS 
which is strange considering many versions of outlook default to try 
that for any secured port other than 25.


I wish more people would use it though.  My users wouldn't have cause to 
get so upset when I tell them that they have to pay monthly for a static 
IP to use tcp/25.  It would reduce my hassles a wee bit.


I have many a time recommended consulting customers to follow up with 
their mail provider to see if they has any plans to support the rfc 
standard, but I dont share much enthusiasm for complete adoption. I do 
believe it is getting better.





Justin

Re: ISP port blocking practice

[Justin Shore]

Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
Few 
companies use the MSP port (tcp/587).


Can you elaborate. Is this based on analysis you've conducted on
your own network? And if so, is the data (anonymized) available for
the rest of us to look at?

My experience is that port 587 isn't used because ISPs block it
out-of-hand.  Or in the case of Rogers in (at least) Vancouver, hijack
it with a proxy that filters out the AUTH parts of the EHLO response,
making the whole point of using the submission service ...  pointless.


I can't speak for Rogers but I have analyzed our netflow captures on a 
semi-regular basis for several things before flushing it, use of the MSP 
port being one of them.  I've never seen any MSP port traffic on my SP 
network that didn't fall into 1 of 2 categories:


1)  inbound scanning for MTAs listening on the MSP port, or
2)  my own MSP traffic or that of family members traffic running across 
my SP network that happen to use one of my personal servers for their 
own email hosting.


I can also speak from experience from the enterprise customers of the 
consulting side of my SP that I worked with before returning to the SP. 
 Not a one of them made use of the MSP port.  The vast majority, I'm 
sorry to say, used Microsoft Exchange which to the best of my knowledge 
doesn't support RFC2476.  I did a little Googling just now and couldn't 
find any hits to say they did either.  Some utilized RPC-over-HTTP. 
Most at the time didn't, requiring direct SMTP access or VPN.


I wish more people would use it though.  My users wouldn't have cause to 
get so upset when I tell them that they have to pay monthly for a static 
IP to use tcp/25.  It would reduce my hassles a wee bit.


Justin

Re: ISP port blocking practice

[Joe Maimon]

Sean Donelan wrote:

On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:

My experience is that port 587 isn't used because ISPs block it
out-of-hand.  Or in the case of Rogers in (at least) Vancouver, hijack
it with a proxy that filters out the AUTH parts of the EHLO response,
making the whole point of using the submission service ...  pointless.


You mentioned this last June.  Can anyone else corroborate it?  Rogers 
says they don't do that, and lots of other people seem to be able to

use port 587 on Rogers (and other ISPs) without problems.

All the cases I've looked at, where someone claimed an ISP was blocking 
port 587, it turned out to be some other problem.  The most common 
reason was related to some security software/host based firewall running 
on the user's own computer.



First thing to check when "email is stuck in my outbox"
Next is to check whether outlook is trying to do SMTPS on 587 instead of 
STARTTLS. Hence 465 SMTPS port workaround.

Re: ISP port blocking practice

[Sean Donelan]

On Thu, 22 Oct 2009, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:

My experience is that port 587 isn't used because ISPs block it
out-of-hand.  Or in the case of Rogers in (at least) Vancouver, hijack
it with a proxy that filters out the AUTH parts of the EHLO response,
making the whole point of using the submission service ...  pointless.


You mentioned this last June.  Can anyone else corroborate it?  Rogers 
says they don't do that, and lots of other people seem to be able to

use port 587 on Rogers (and other ISPs) without problems.

All the cases I've looked at, where someone claimed an ISP was blocking 
port 587, it turned out to be some other problem.  The most common reason 
was related to some security software/host based firewall running on the 
user's own computer.

Re: IPv6 Deployment for the LAN

[Perry Lorier]

trej...@gmail.com wrote:
WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? 

  
You want to allow for more than one for obvious fault isolation and load 
balancing reasons.  The draft suggested using :::1 I 
personally would suggest getting a well known ULA-C allocation assigned 
to IANA, then use :::1 ::assignment>:2 and :::3, where assignment> could be "0035" for DNS, and "007b" for NTP, and if you're 
feeling adventurous you could use "0019" for outgoing SMTP relay.





... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 
for this type of "ULA port-based anycast allocation". (16bits would only reach 
 w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less 
obvious))


Easily identified, not globally routable, can be pre-programmed in 
implementations/applications ... ?

  


Exactly, seems easy, straight forward, robust, reliable and allows for 
things like fate sharing and fail over.

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Perry Lorier]

David W. Hankins wrote:

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
  

Really.  How do we deal with rouge DHCP on the wireless LAN, obviously
this is such a complex issue that we couldn't possibly have a solution
that could be applied to RA.



There are some wireless equipment that claim to have a setting that
forces all packets through the wireless bridge (where all traffic is
between clients and bridge, and never client to client), and so one
can filter DHCPv6 and maybe RA, but I am kind of skeptical about how
much of this is elective and dependent upon client implementation...
  


When you're associated to an AP, you're in a "managed" wireless network, 
where all traffic *must* go through the AP.


I've implemented myself a system which firewalled all ARP within the AP 
and queried the DHCP server asking for the correct MAC for that lease 
then sent the ARP back (as well as firewalling DHCP servers and the 
like).  It's quite easily doable, and quite reliable.  If nodes were to 
send packets directly when associated to an AP then the 802.11 protocol 
would fall apart, I've never met an implementation that broke this 
requirement of the standard.



In both cases there may still be some wireless adapters that receive
bogus packets directly from attackers.
  


You can of course pretend you're the AP and send a packet if you're 
wanting to be vicious enough.

Re: IPv6 Deployment for the LAN

[David W. Hankins]

On Fri, Oct 23, 2009 at 10:25:10AM +1100, Karl Auer wrote:
> I think it was really this that I was wanting more info on. "Entered"
> where?

On the address configured on the interface typically, or whatever
other system specifical local means are used to enter a route for the
prefix for the interface.

Typically on Linux;

  ip=/sbin/ip
  ${ip} -f inet6 addr add ${new_ip6_address}/${new_ip6_prefixlen} \
dev ${interface} scope global

-- 
David W. Hankins"If you don't do it right the first time,
Software Engineeryou'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgpLidDFvZOvH.pgp
Description: PGP signature

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[David W. Hankins]

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
> Really.  How do we deal with rouge DHCP on the wireless LAN, obviously
> this is such a complex issue that we couldn't possibly have a solution
> that could be applied to RA.

There are some wireless equipment that claim to have a setting that
forces all packets through the wireless bridge (where all traffic is
between clients and bridge, and never client to client), and so one
can filter DHCPv6 and maybe RA, but I am kind of skeptical about how
much of this is elective and dependent upon client implementation...

In both cases there may still be some wireless adapters that receive
bogus packets directly from attackers.

And then you bring ND into the question and wonder why you bothered
with either RA or DHCP filtering.


DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic
authentication.

The problem however has been the key distribution model.  Here it all
falls down, and leads to poor deployment.

But with DHCPv*, we have a hope that we can secure it if we can solve
that last problem (and at least I think we can).

So if you accept that as an outcome, one must ponder the question:

How long will people accept that a secured DHCPv6 session must rely,
in order to function to expectations, upon the unsecurable RA and/or
questionably secure SEND?

-- 
David W. Hankins"If you don't do it right the first time,
Software Engineeryou'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgpf4lygcPQdK.pgp
Description: PGP signature

Re: ISP port blocking practice

[Justin Shore]

Zhiyun Qian wrote:
1). For any outgoing traffic, if the destination port is 25, then drop 
the packets.
2). For any incoming traffic, if the source port is 25, then drop the 
packets.


It's been pointed that I glossed over the wording of #2, specifically 
missing the "source port" part of it, thus giving the right answer to 
the wrong question.  :-)


To answer your question, all our tcp/25 filters are based on destination 
port.  I could use source port but really I'm more concerned with my 
customers not running SMTP servers in one direction and them not being 
able to send spam in the other.  Using source port needlessly 
complicates those goals IMHO.  Someone might have a specific reason to 
use it but I don't in my case at least.


Justin

Re: IPv6 Deployment for the LAN

[Joe Maimon]

Ray Soucy wrote:




Others may have their specific requests from vendors, but here are mine:

1. Include DHCPv6 client functionality as part of any IPv6 implementation.
2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure.


I can agree with that.

I would also add that there is plenty of work that can be done to DHCP, 
such as adding full route support, multiple gateways with preference and 
even transitioning from a binary only protocol.




A lot of the frustration seems to come from Windows ICS acting as an
IPv6 router.  I think everyone here has been after Microsoft to either
remove ICS or make it more difficult to enable at one point or
another.  While a rogue RA can come from anywhere, Windows is usually
the guilty party.  I would argue that since NAT is not a component of
IPv6,


NAT wasnt a component of IPv4 until it was already had widespread 
adoption. I remain completely unconvinced that people will not continue 
to perceive value in PAT6 between their private and their public subnets.


And of course, different forms of NAT are almost certainly required to 
try to make ipv4 and ipv6 interoperate for as long as people need it to.



no host should be implementing ICS-like functionality for IPv6.
It's unlikely that there would be a situation on an IPv6 network that
a host needed to share it's IPv6 address to get others online.

Just my thoughts.  Maybe someone from Microsoft who can do something
about it lurks on this list.



Good luck.

Joe

Re: IPv6 Deployment for the LAN

[Karl Auer]

On Thu, 2009-10-22 at 16:16 -0700, David W. Hankins wrote:
> Unless of course it can fall back on native IPv4, or has entered a
> bogus covering /64.

I think it was really this that I was wanting more info on. "Entered"
where?

Sorry to be obtuse, clearly I am missing something obvious.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF



signature.asc
Description: This is a digitally signed message part

Re: IPv6 Deployment for the LAN

[Joe Maimon]

Iljitsch van Beijnum wrote:

On 22 okt 2009, at 22:52, Mark Smith wrote:


Seriously, we're all adults.  So treating us like children and
taking away the power tools is not appreciated.



Stop trying to break the internet and I'll treat you like an adult.




Great way to shoot down your own credibility. Just because you don't
have or don't understand problems other people have doesn't mean they
don't have them or they're invalid.


When people want something which is clearly a bad idea (doing default 
gateways in DHCPv6 the same way as in DHCPv4) and they ignore it when a 
better solution is suggested (having a DHCP option that allows a DHCPv6 
server to tell hosts which of the available routers to use) then the 
discussion tends to take a turn for the worse.



Thats your opinion. However ICMP router advertisment and before that RIP 
have always been available to provide default router in IPv4 and the 
userbase has already decided which they prefer. History is not on your 
side on this one.


That doesnt mean that DHCPv6 could not do a better job, such as being 
able to configure hosts with multiple specific routes, including a 
default one, or being able to tell hosts to use RA or which potential RA 
learnt gateways should be used and in which preference order.


But requiring default gateway information be learnt from RA and that RA 
be operational for DHCPv6 operation is as clearly to me a bad idea as is 
allowing people to use DHCP with ipv6 in a manner they have come to rely 
on it for IPv4 is to you.


A DHCP server that requires a working router RA is like having a 3 
legged race.




But wouldn't hardcoding a prefix length also be a bad idea? We now 
pretty much always have /64 but there are just enough exceptions to make 
it dangerous to just assume /64.


There is no reason to assume we will be stuck with /64. Once upon a time 
nobody thought subnet masks would ever be anything longer than /24 /16 
or /8 depending on the first few bits in the address. I dont think that 
lasted very long and was completely erased by CIDR adoption.


The one lesson we should be taking from that is not to assign magic and 
sacred powers to bit boundaries.




However, I firmly believe that whether is done with DHCPv6 it will 
continue to have problems. Even if DHCPv6 itself would operate well and 
consistently in all cases, then there are still the permuations between 
hosts that support stateless autoconfig and not DHCP, those that support 
both, those that are configured to only do DHCP, those that listen for 
the M/O bits and those that don't...



So in effect, you are saying that now that this mess has been created 
over peoples strenuous objections that they are forced to live with it?


Thats not going to win any arguments.

And in any effect, you are probably making the point that using non /64 
subnet lengths with a properly operational DHCPv6 is actually a good 
idea for those who wish to completely skip all RA.


Joe

Re: IPv6 Deployment for the LAN

[David W. Hankins]

On Thu, Oct 22, 2009 at 11:12:14AM +1100, Karl Auer wrote:
> > To work around this problem, some DHCPv6 software implementers have
> > elected to temporarily apply a fixed /64 bit prefix to all applied
> > addresses until a prefix length can be made available in-band through
> > some means.  This does neatly work around the problem; the hosts may
> > now speak to one another.
> 
> I don't understand this. Could you elaborate? It seems to me that the
> "simplest network imaginable" should still operate on link local
> addresses.

To use a link local address, you also have to supply the application
with the interface name for it to be used upon.  The application has
to pass this as an extra argument when opening a socket; it isn't part
of the regular gethostbyname/socket/connect.

Provided you have applications that have a separate dialog field for
the interface name so LL's can be used, you're probably going to be
entering in the IPv6 LL address in all its glory.  First, you are not
going to have LL addresses in /etc/resolv.conf because you can't list
interface names there (I think it is the same for other OS's
analogues of their nameservers list), and second people are not going
to be very well motivated to put LL addresses in DNS because those
addresses are not globally applicable; they would have to use DNS
views.

So it is not really very realistic to expect LL to actually be used
except to bootstrap.

Maybe it's possible for some proprietary printer or fileshare network
stuff to continue working on LL's (or, ironically, routing protocols
or DHCPv6 itself), but anywhere else ("mail.example.com",
"contacts.example.com"), anywhere real, and the network goes dark.

Unless of course it can fall back on native IPv4, or has entered a
bogus covering /64.

-- 
David W. Hankins"If you don't do it right the first time,
Software Engineeryou'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins


pgpK1IOWTvfyQ.pgp
Description: PGP signature

Re: ISP port blocking practice

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> Few 
> companies use the MSP port (tcp/587).

Can you elaborate. Is this based on analysis you've conducted on
your own network? And if so, is the data (anonymized) available for
the rest of us to look at?

My experience is that port 587 isn't used because ISPs block it
out-of-hand.  Or in the case of Rogers in (at least) Vancouver, hijack
it with a proxy that filters out the AUTH parts of the EHLO response,
making the whole point of using the submission service ...  pointless.

--lyndon

Re: IPv6 Deployment for the LAN

[Karl Auer]

On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote:
> > If, on the other hand, the REAL desire is to have a DHCP server break 
> > the tie in the selection between several routers that advertise their 
> > presence, that wouldn't be unreasonable.
> 
> In some configurations not all hosts are supposed to use the same
> router.  We need the _option_ to specify a default gateway and
> have the override any RA's a host may see.

It would be a tool, and if someone wants to use a tool, they can. It
won't be my thumb they hit :-)

But I can't see how a DHCP server can know enough about the routers to
be able to send out useful discrimination information. So it will have
to be manually entered, or come from an IPAM, or...

Nor can I see how the DHCP server can identify the routers to the host
except by their addresses, and these can change or be removed without
the DHCP server finding out.

The only way I can see it working is if the host were smart enough to
compare the DHCP router discrimination info with the information it has
received via RA and delete mismatches, or possibly just revert to using
RA information if any mismatches at all are detected. That would be an
item the DHCP server could specify as well - what to do in case of a
mismatch. It could even be specified on a per-router basis, though the
whole thing seems to be getting a bit unwieldy now.

The DHCP servers will not be on the same subnets as all the routers
involved, so they can't sniff the RAs themselves - unless we set up an
RA relay... hmm.

I don't see DHCP-delivered router preferences as being something that
will "break the Internet". In the vast majority of cases they will be
unnecessary. For those that do need it though, and if it can be done,
why not?

Regards, K.


-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF



signature.asc
Description: This is a digitally signed message part

Re: IPv6 Deployment for the LAN

[Perry Lorier]

bmann...@vacation.karoshi.com wrote:

On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote:
  
You could imagine extending this to other services such as NTP, but I'm 
not sure that you really would want to go that far, perhaps using DNS to 
lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.


Another obvious approach might be to have a service discovery protocol 
where you send to a "service discovery" multicast group a message asking 
"wheres the nearest nameserver(s)?" then nameserver implementations 
could listen on this multicast group and reply.  Again shared fate.  
This does have the downside of people running rogue nameservers and 
needing a "ServiceDiscovery-Guard" feature for switches 



ah... well - if your a router centric person, then you want
to put everything into the tools you know and love.

  


Generally I don't think of myself as a router centric person ;)


if your a dns centric person, then you put everything in the
DNS.

  


This has always sounded like a nice solution to me, however, DNS is 
starting to look a little long in the tooth, overloading it with more 
and more semantics seems to be pushing it well beyond it's design 
envelope.  (EDNS0?)



I point you to the "DISCOVER' opcode (experimental) in the DNS
and the use of DNS over multicast for doing service discovery
(e.g. Apples Bonjour)...  Most of that is already designed/deployed
and in pretty widespread use... over IPv4 or IPv6.
  


Yup, they're good ways to discover some local resources.  To my 
understanding mDNS works over the local subnet, unless you're going to 
start having your routers run as mDNS relays (is there any standards for 
this?  How do you stop mDNS relays from creating loops and broadcast 
storms?).  mDNS works over a a single multicast group with a single port 
5353 which makes it hard to filter different types of services (People 
on this switch can announce their iTunes sharing, but they're not 
allowed to announce a local DNS server) without DPI, you're more likely 
to find network engineers just filter the entire multicast group 
breaking it for other purposes  If you're not going to have mDNS 
forwarders on your routers, then you're going to need to reconfigure 
your entire configuration on every segment as well.


(IMHO) there are different types of configuration:

* Network related (routes, addressing).  RA's seem to do a fairly good 
job at at least 80% of this.


* Network provided services, such as DNS, NTP.  Well known anycast 
addresses seems to be (IMHO) the best way to advertise these.  Currently 
you need DHCPv6 to get this information.


* Application settings (web proxy, local outgoing SMTP relay, default 
printer location, local SIP/RTP proxy, local home/intranet page, what 
the current local timezone rules are).  This seems to be currently done 
by a variety of adhoc protocols, usually bundled over well known DNS 
names with HTTP, often replicating the same information in a wide range 
of different places in different formats.  This seems an ugly solution, 
but I have no other suggestions.  I'm sure there are several RFCs/Drafts 
around somewhere that tries to solve this.


* Ephemeral end user provided services, which is already provided today 
by the well documented, and deployed mDNS.


in theory you can kinda pick and choose between those, for instance you 
can run just mDNS on a network without RA's or DHCPv6 and things will 
work (for the limited value of work that involves only whatever the 
ephemeral services are being announced).  You can run RA's by 
themselves, and your bittorrent will work fine.

And yes, its not RA/ND, or DHCP... its another configuration protocol
and its not quite vendor specific.  The best thing is, it pushes
the smarts closer to the edge (the end device)  and this makes me happy.

  
Theres a general issue of access control.  While I like a very smart 
edge, you don't want some ""misinformed"" user turning on a feature and 
suddenly having the rest of your network ending up using it. 



Personally I like the first option (anycast addresses) better, you can 
control who has access to your IGP and if your IGP is down, then for all 
intents and purposes your recursive nameservers are offline too :)





everyone to their own taste.

  


Yup.  There are different systems, they have different tradeoffs.  Pick 
the one that trades off things you don't care about for things you do 
care about. :)

Re: ISP port blocking practice

[Justin Shore]

Zhiyun Qian wrote:

Hi all,

What is the common practice for enforcing port blocking policy (or what 
is the common practice for you and your ISP)? More specifically, when 
ISPs try to block certain outgoing port (port 25 for instance), they 
could do two rules:
1). For any outgoing traffic, if the destination port is 25, then drop 
the packets.
2). For any incoming traffic, if the source port is 25, then drop the 
packets.


I block on both generally.  I block inbound and outbound for residential 
customers in dynamic pools.  I block inbound only for residential with 
statically-assigned IPs.  That way a customer can request (and pay for) 
a static IP and be able to get around out outbound SMTP block.  Few 
companies use the MSP port (tcp/587).  I'm not sure why more don't make 
the effort but most don't.  To make up for that we allow static 
residential customers to evade that filter with a static IP.  We still 
block inbound though.  We also allow them to use our SMTP servers and 
SmartHosts if they want with no requirements on source domains (like 
some providers require, essentially requiring the customer to advertise 
for you).  The inbound block isn't really all that useful as you elude 
to.  However I use it more often than not to look for people scanning 
out ranges for open relays.  I use that data for feed my RTBH trigger 
router and drop the spammer's traffic on the floor (or the poor, 
unfortunate owner of the compromised PC that's been 0wned.


We block several other things too.  Netbios traffic gets dropped both 
ways.  MS-SQL traffic gets dropped both ways (a few users have 
complained about this but very few stick to their guns when you point 
out that their traffic is traversing the web completely unencrypted).  I 
block default and common proxy ports such as 3128, 7212, and 6588 in 
both directions.  Squid is too easy to misconfigure (done it myself). 
GhostSurf and WinGate have both been abusable as open proxies in various 
releases.  I also block 8000, 8080 and 8081 towards the customers. 
These are some of our most commonly scanned ports (usually all 3 at once 
plus some or all of the 80xx ones).  I've encountered many compromised 
residential CPEs that the users either enabled themselves or were 
enabled by default.  I don't block those 3 ports on outbound flows 
though; too many false positives.


And finally we also block several different types of ICMPs.  First off 
we block ICMP fragments.  Then we permit echo, echo-reply, 
packet-too-big, and time-exceeded.  The rest get explicitly dropped. 
IPv6 will change this list dramatically.  I haven't had time to research 
ICMPv6 thoroughly enough to say any more than that.


Basically I just pick out some of the really bad ports and block them. 
This gives me a wealth of data with which to null-route compromised PCs 
scanning my networks.


Also, is it common that the rules are based on tcp flags (e.g. SYN, 
SYN-ACK)? One would think block SYN packet is good enough.


I don't get that deep into it.  Forged packets of types other than SYN 
can still reek havoc on existing flows.  I think it's better to block 
all and move on.


Justin

Re: Need a clueful Telia AS1299 engineer

[Adam Rothschild]

On 2009-10-22-16:19:53, Jeffrey Lyon  wrote:
> Could a clueful AS1299 engineer please drop me a line? Dealing with
> the Level 0 technicians that are offered to IC clients is completely
> useless in diagnosing a rather serious issue.

r...@telia.net is a good place for routing/policy-related inquiries, or
carrier-...@teliasonera.com for more time-sensitive issues.  Both can
provide a quick escalation path to clue and enable.

I've amassed some individual contacts from being a customer, which I'd
be happy to share off-list...

-a

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[John Payne]

On Oct 22, 2009, at 4:32 PM, Ray Soucy wrote:


Knowing about it the
instant it happens might even be better than slowly coming to the
realization that you're dealing with one.


Might just be me, but I'm more worried about the rogue RA (or DHCPv4)  
server that does not disrupt communication at all...

Re: IPv6 Deployment for the LAN

[Iljitsch van Beijnum]

On 22 okt 2009, at 22:52, Mark Smith wrote:


Seriously, we're all adults.  So treating us like children and
taking away the power tools is not appreciated.



Stop trying to break the internet and I'll treat you like an adult.




Great way to shoot down your own credibility. Just because you don't
have or don't understand problems other people have doesn't mean they
don't have them or they're invalid.


When people want something which is clearly a bad idea (doing default  
gateways in DHCPv6 the same way as in DHCPv4) and they ignore it when  
a better solution is suggested (having a DHCP option that allows a  
DHCPv6 server to tell hosts which of the available routers to use)  
then the discussion tends to take a turn for the worse.



You'd be far better off proposing
alternative solutions that use methods that you believe in, or looking
to understand better why your methods aren't appropriate.


I often do that. Unfortunately, in many cases, people not only insist  
on bad ideas, but they won't even take suggestions on how to achieve  
what they want in less harmful ways. That annoys me a great deal.



(I don't believe in your agenda to add a prefix length option to
DHCPv6 (you probably haven't run an IPX or Appletalk network, and
therefore haven't experienced the convenience of fixed length
subnets/node addresses), but I don't think it's appropriate to call  
you

a child because of you naivety in this area ...)


But wouldn't hardcoding a prefix length also be a bad idea? We now  
pretty much always have /64 but there are just enough exceptions to  
make it dangerous to just assume /64.


However, I firmly believe that whether is done with DHCPv6 it will  
continue to have problems. Even if DHCPv6 itself would operate well  
and consistently in all cases, then there are still the permuations  
between hosts that support stateless autoconfig and not DHCP, those  
that support both, those that are configured to only do DHCP, those  
that listen for the M/O bits and those that don't... There's simply no  
way to get consistent behavior out of a set of hosts unless those  
hosts all run the same version of the same OS. Now for anything else  
than a configuration protocol that wouldn't be a disaster but for a  
configuration protocol this is fairly inconvenient.

Re: ISP port blocking practice

[Ricky Beam]

On Thu, 22 Oct 2009 13:22:17 -0400, Zhiyun Qian  wrote:
1). For any outgoing traffic, if the destination port is 25, then drop  
the packets.
2). For any incoming traffic, if the source port is 25, then drop the  
packets.


Inspecting outgoing traffic is generally easier to do as there's less of  
it. (in a consumer context, which is the only place such filtering makes  
any sense.)


--Ricky

Re: IPv6 Deployment for the LAN

[Ray Soucy]

It's certainly encouraging to see how there is such consensus among
NANOG on IPv6 deployment. :-)

Recent exchanges seem to be getting a little personal, so we might
want to take a step back and breath.

I don't think adding default gateway support to DHCPv6 will have much
of an impact, but I'm OK with people trying to get it implemented.
Another tool in the box.  I just wouldn't hold your breath waiting for
it.

I think the better approach is to take a firm stand on security and
make RA gaurd and DHCPv6 snooping expected for network devices.  These
problems will still exist if default gateway options for DHCPv6 get
implemented.

As for RA taking down a network quickly, well, it can be restored
quickly too.  The fact that RA is actually responsive can be a benefit
in some situations.

Hopefully if anything has come out of this thread its that both
stateless and stateful configuration have a place in IPv6, and that
there is still work to be done before IPv6 is really ready for the
enterprise LAN.

Others may have their specific requests from vendors, but here are mine:

1. Include DHCPv6 client functionality as part of any IPv6 implementation.
2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure.

A lot of the frustration seems to come from Windows ICS acting as an
IPv6 router.  I think everyone here has been after Microsoft to either
remove ICS or make it more difficult to enable at one point or
another.  While a rogue RA can come from anywhere, Windows is usually
the guilty party.  I would argue that since NAT is not a component of
IPv6, no host should be implementing ICS-like functionality for IPv6.
It's unlikely that there would be a situation on an IPv6 network that
a host needed to share it's IPv6 address to get others online.

Just my thoughts.  Maybe someone from Microsoft who can do something
about it lurks on this list.

-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[TJ]

>
>
>>> Then let me say it. RA needs to be able to be completely turned off.
> DHCPv6 needs to be able to completely configure all requesting hosts.


Those two statements are not synonymous ...


Sure, leave RA in the IPv6 stack. The market will decide, and we will see if
> it is still on by default on soho routers and in IOS 15.4T in 2015.
>
> That is a more sensible statement.  And were I to be a gambling man I would
say it will indeed be on by default ... we'll talk more about it then :).


Also, I would like to add - there is a difference between the default
gateway information and other things, such as NTP|DNS|SIP server
information.
The default gateway, by definition, is an on-link thing.  IMHO, this makes
the router a good source for information about the router.
I am not saying use cases for "fully spec'ed DHCPv6" don't exist or should
be ignored.
Making the router capable of sharing the "missing piece" that covers ~95% of
use cases is also a Good Thing.

Thinking out loud, we could also re-create the idea of an auto-magic DNS by
creating a special use case within ULA-space - say FD00::/96, saving the
last 32 bits for something like ::53 and using anycast.
*(Could abstract same idea to any stateless and/or light-session-based
service ... FD00::123 for Automagic ULA-based anycast NTP, etc.  Need 32
bits if we don't want to hex convert the > things, just in case ...)*


/TJ

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[TJ]

>
>
> Port based solutions don't work well on wireless networks and other
> mediums.
>
> Something like PSPF then? (assuming it works properly on IPv6 multicast ...
)


/TJ

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Joe Maimon]

Owen DeLong wrote:




Not at all.  People are not saying RA has to go away.  They are saying we
need the option of DHCPv6 doing the job where we do not feel that RA is
the correct tool.


Then let me say it. RA needs to be able to be completely turned off. 
DHCPv6 needs to be able to completely configure all requesting hosts.


DHCPv4 works everywhere and meets every networks needs, from the $50 
linksys to the million dollar network. RA already does not.


The answer to RA shortcomings is not to turn it into a clone of DHCP, 
only stateless and chained to the router.




More tools are good.  Replacing one tool that works today with a new tool
that is arguably inferior in many real world cases, on the other hand, is
not so good.

Owen



Sure, leave RA in the IPv6 stack. The market will decide, and we will 
see if it is still on by default on soho routers and in IOS 15.4T in 2015.


Joe

Re: IPv6 Deployment for the LAN

[Mark Smith]

On Thu, 22 Oct 2009 11:40:50 +0200
Iljitsch van Beijnum  wrote:

> On 21 okt 2009, at 22:48, Owen DeLong wrote:
> 
> > The assumption that the router "knows" it is correct for every host  
> > on a given
> > LAN simply does not map to reality deployed today.
> 
> What I'm saying is that a router knows whether it's a router or not. A  
> DHCP server does not, so it has to make a leap of faith and then  
> sometimes the hosts fall flat on their face if there's no router on  
> the address indicated by the DHCP server. The counter-argument is "it  
> works today" but my counter-counter-argument is "it doesn't work  
> today". I get burned by broken DHCP setups _all_ _the_ _time_ at work,  
> at IETF meetings, at RIPE meetings, etc.
> 
> Anyone claiming that having a DHCP server direct hosts to a router  
> address in the blind is simply incompetetent, so there is no point in  
> listening to them.
> 
> If, on the other hand, the REAL desire is to have a DHCP server break  
> the tie in the selection between several routers that advertise their  
> presence, that wouldn't be unreasonable.
> 
> > Please explain to me how I can achieve this functionality in RA/SLAAC
> > or stop pushing to prevent it from being available in DHCPv6.
> 
> There is no requirement that the IETF provides all functionality that  
> someone can think up. The list of desired functionality is infinite,  
> and much on that list is a bad idea and/or can be achieved in  
> different ways.
> 
> > Seriously, we're all adults.  So treating us like children and  
> > taking away
> > the power tools is not appreciated.
> 
> Stop trying to break the internet and I'll treat you like an adult.
> 

Great way to shoot down your own credibility. Just because you don't
have or don't understand problems other people have doesn't mean they
don't have them or they're invalid. You'd be far better off proposing
alternative solutions that use methods that you believe in, or looking
to understand better why your methods aren't appropriate.

(I don't believe in your agenda to add a prefix length option to
DHCPv6 (you probably haven't run an IPX or Appletalk network, and
therefore haven't experienced the convenience of fixed length
subnets/node addresses), but I don't think it's appropriate to call you
a child because of you naivety in this area ...)

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[David Barak]

 Original Message 
From: Ray Soucy 

>Or is it that you want IPv6 to be a 128-bit version of IPv4?  


Yes, this is in fact exactly what the network operators keep saying.  

>RA is a
>good idea and it works.  You can add options to DHCPv6, but I don't
>see many vendors implementing default gateway support unless you can
>make a real case for it.
>My fear is that your goal is to do away with RA completely and turn to
>DHCPv6 for all configuration.  RA is actually quite nice.  You really
>need to stop fighting it, because it's not going away.

RA may be quite nice for some cases.  However, several examples over this 
thread alone have been provided about some other cases where it is something 
other than nice.  

DHCPv4 is not a perfect protocol, but it's widely deployed and understood.  It 
also is a one-stop-shop for centralized host configuration.  IPv6 does not 
currently have a similar one-stop-shop protocol, and this is a major gap in 
functionality.  There are a bunch of very large providers and enterprises which 
number their DHCP-managed end-sites in the hundreds of thousands or millions.  
The inability to provide the same centralized configuration management should 
not be considered a feature.


David Barak
Need Geek Rock? Try The Franchise: 
http://www.listentothefranchise.com

Re: IPv6 Deployment for the LAN

[Mark Smith]

On Thu, 22 Oct 2009 21:20:11 +1100
Karl Auer  wrote:

> On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
> > If, on the other hand, the REAL desire is to have a DHCP server break  
> > the tie in the selection between several routers that advertise their  
> > presence, that wouldn't be unreasonable.
> 
> The RA contains a preference level... maybe that doesn't cut it if
> multiple routers are sending the same preference level, but presumably
> that would not happen in a well-tended network.
> 

IPv6 Subnets/VLANs are pretty cheap, maybe if people are having this
issue, that's a sign they need to divide their hosts into more
subnets/VLANs.

More broadly, it seems the argument is where to put networking
operational policy - in the network (via e.g. engineered topology), or
on the hosts. I think there is value in putting it in the network,
because it avoids having to change host located policy when the
network policy changes. 

> In any case, anywhere this is actually of vital importance, a routing
> protocol would be in use.
> 
> Using the DHCP protocol to deliver information - about anything really -
> is what it's *for*. That said, making clients depend utterly on the
> presence of a working DHCP server for basic connectivity seems like a
> backward step. Of course, different people have different ideas about
> what constitutes "basic" connectivity.
> 
> > Stop trying to break the internet and I'll treat you like an adult.
> 
> Whoa! Tell you what, how about if I break it, and you get to choose
> which piece you keep? [Bash, bash, thud. Ugh. Hm. It's tougher than it
> looks!]
> 
> :-)
> 
> Regards, K.
> 
> -- 
> ~~~
> Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
> http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)
> 
> GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
> 

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Owen DeLong]

On Oct 22, 2009, at 12:23 PM, Ray Soucy wrote:


This to me is one of the least credible claims of the RA/SLAAC crowd.
On the one hand we have carriers around the world with millions and
millions of customers getting default routes and other config through
DHCPv4 every day. And most of the time it actually works very well!

On the other hand we have RA/SLAAC with a vastly smaller customer
base, vastly less real life testing - but which is still claimed to
be so much better that DHCPv6 is not *allowed* to get a default route
option.


If the argument against RA being used to provide gateway information
is "rogue RA," then announcing gateway information though the use of
DHCPv6 doesn't solve anything.  Sure you'll get around rogue RA, but
you'll still have to deal with rogue DHCPv6.  So what is gained?


Apparently you missed the entire message he responded to about the
number of things specified by DHCP and the differences between the
groups in control of the routers vs control of the hosts/servers and the
actual administrative groups in charge of each?


I guess I'm not really seeing the case here.  Are people really making
use of DHCP to provide hosts on the same network with different
default gateway information?  If so, why?


Yes.  A number of different application and business requirements. Some
I can go into easily (load balancing among different routers, routers  
owned
by different departments, etc.), some are proprietary to my clients  
and I can't

give enough details without violating NDA.


Or is it that you want IPv6 to be a 128-bit version of IPv4?  RA is a
good idea and it works.  You can add options to DHCPv6, but I don't
see many vendors implementing default gateway support unless you can
make a real case for it.

The assignment of gateway information to the host belongs in the hands  
of the

systems administrators and not in the hands of the people running the
switches and routers in many organizations.

With router information assigned through DHCP, this is preserved.   
With it
being assigned by the router, it is not, and, in fact, the case.  With  
DHCPv6
unable to assign router information you lose that administrative  
boundary

and take away a systems administrators control over their hosts and hand
it to the networking group.


My fear is that your goal is to do away with RA completely and turn to
DHCPv6 for all configuration.  RA is actually quite nice.  You really
need to stop fighting it, because it's not going away.

Not at all.  People are not saying RA has to go away.  They are saying  
we

need the option of DHCPv6 doing the job where we do not feel that RA is
the correct tool.

More tools are good.  Replacing one tool that works today with a new  
tool
that is arguably inferior in many real world cases, on the other hand,  
is

not so good.

Owen

Re: IPv6 Deployment for the LAN

[Dan White]

On 22/10/09 16:06 -0400, Chuck Anderson wrote:

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:

Really.  How do we deal with rouge DHCP on the wireless LAN, obviously
this is such a complex issue that we couldn't possibly have a solution
that could be applied to RA.


Rogue DHCP doesn't immedately take down the entire subnet of machines 
with existing DHCP leases.  It generally only affects new machines 
trying to get a lease, or RENEWing machines.  The impact of a rogue RA 
is to immediately break connectivity for every machine on the subnet.  
Differing impacts leads to different risk assessments of which 
protocol to use.


That breaks both ways. You could do maintenance in the middle of the night
and break DHCP in unexpected ways (which I've seen happen) and then you
have the problem of manually rebooting (or renewing) all those devices the
next morning when you notice they're not working.

We really just need to bug our vendors to implement Rogue RA 
protection for wired and wireless ASAP, wherever we are in our 
deployment of IPv6.


VLAN per subscriber fixes this. It's not really appropriate everywhere, but
it's a nice solution for wireless and ISP scenarios.

--
Dan White

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Ray Soucy]

Correct.

Not sure if you got the sarcasm in that last reply...

As far as I'm concerned, a rogue is a rogue.  Knowing about it the
instant it happens might even be better than slowly coming to the
realization that you're dealing with one.  The point is that we need
to address rogues regardless of their type, not move from RA to DHCPv6
because the impact of a rogue is slower to disrupt service.

On Thu, Oct 22, 2009 at 4:06 PM, Chuck Anderson  wrote:
> On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
>> Really.  How do we deal with rouge DHCP on the wireless LAN, obviously
>> this is such a complex issue that we couldn't possibly have a solution
>> that could be applied to RA.
>
> Rogue DHCP doesn't immedately take down the entire subnet of machines
> with existing DHCP leases.  It generally only affects new machines
> trying to get a lease, or RENEWing machines.  The impact of a rogue RA
> is to immediately break connectivity for every machine on the subnet.
> Differing impacts leads to different risk assessments of which
> protocol to use.
>
> Regardless, modern wireless deployments use central controllers or
> smart APs that can filter DHCP.  They could be extended to filter RA
> as well.
>
> And this whole point is rather moot because we have RAs and must deal
> with them.  It is too late to get rid of the RA behavior of clients.
> Even if you don't want to use RAs, your hosts are going to still
> listen to them which means a Rogue RA is going to take down your
> network.  We have this problem even on IPv4-only subnets, where a
> Rogue RA (usually a Windows box with routing turned on) breaks
> connectivity to dual-stack servers for machines on that subnet.  Since
> the hosts prefer native IPv6 connectivity over IPv4, the hosts end up
> preferring the Rogue RA as the route towards the dual-stack server.
>
> We really just need to bug our vendors to implement Rogue RA
> protection for wired and wireless ASAP, wherever we are in our
> deployment of IPv6.
>
>



-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

Re: IPv6 Deployment for the LAN

[David Conrad]

Tony,

On Oct 22, 2009, at 12:41 PM, Tony Hain wrote:
> The root of the argument I see in this entire thread is the assumption that
> 'what we have for IPv4 has *always* been there'.

Well, no.  My reading is "what we have for IPv4 works, scales well, we're 
accustomed to it, and our provisioning systems are all built around it'.

> There is lots of finger
> pointing at the IETF for failure to define 15 years ago, what we have
> evolved as the every-day assumptions about the IPv4 network of today.

Well, no.  My reading is that there is finger pointing at the IETF for ignoring 
and/or denying what network operators are specifying.

> The real issue here
> is that some people are so locked into one approach that they refuse to even
> consider that there might be an alternative way to achieve the same goal, or
> that the actual goal will change over time in the face of external
> requirements. 

Actually, I think the issue is that there are folks who are running real, live 
businesses who don't really have the time (or interest) to experiment with 
alternative ways of doing things.  They're getting pressure to deploy new stuff 
and are looking for technologies that are the quickest, easiest, requires the 
least retraining, retooling, redeployment, etc.  They then get folks (most of 
which do not run real, live non-trivial networks) who say "use this new shiny 
toy!" and block efforts to hack the existing tools.

It's that last bit that's the problem.

But then again, I'm just guessing since I don't run a real, live non-trivial 
network...

Regards,
-drc

Need a clueful Telia AS1299 engineer

[Jeffrey Lyon]

Could a clueful AS1299 engineer please drop me a line? Dealing with the
Level 0 technicians that are offered to IC clients is completely useless in
diagnosing a rather serious issue.

-- 
Jeffrey Lyon, Leadership Team
jeffrey.l...@blacklotus.net | http://www.blacklotus.net
Black Lotus Communications of The IRC Company, Inc.

Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to
find out how to "protect your booty."

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Chuck Anderson]

On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote:
> Really.  How do we deal with rouge DHCP on the wireless LAN, obviously
> this is such a complex issue that we couldn't possibly have a solution
> that could be applied to RA.

Rogue DHCP doesn't immedately take down the entire subnet of machines 
with existing DHCP leases.  It generally only affects new machines 
trying to get a lease, or RENEWing machines.  The impact of a rogue RA 
is to immediately break connectivity for every machine on the subnet.  
Differing impacts leads to different risk assessments of which 
protocol to use.

Regardless, modern wireless deployments use central controllers or 
smart APs that can filter DHCP.  They could be extended to filter RA 
as well.

And this whole point is rather moot because we have RAs and must deal 
with them.  It is too late to get rid of the RA behavior of clients.  
Even if you don't want to use RAs, your hosts are going to still 
listen to them which means a Rogue RA is going to take down your 
network.  We have this problem even on IPv4-only subnets, where a 
Rogue RA (usually a Windows box with routing turned on) breaks 
connectivity to dual-stack servers for machines on that subnet.  Since 
the hosts prefer native IPv6 connectivity over IPv4, the hosts end up 
preferring the Rogue RA as the route towards the dual-stack server.

We really just need to bug our vendors to implement Rogue RA 
protection for wired and wireless ASAP, wherever we are in our 
deployment of IPv6.

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Ray Soucy]

Really.  How do we deal with rouge DHCP on the wireless LAN, obviously
this is such a complex issue that we couldn't possibly have a solution
that could be applied to RA.

On Thu, Oct 22, 2009 at 3:50 PM, Leo Bicknell  wrote:
> In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy 
> wrote:
>> The solution here, and one that is already being worked on by vendors,
>> is RA gaurd, not changing DHCPv6 in an effort to bypass RA.
>
> Port based solutions don't work well on wireless networks and other
> mediums.
>
> --
>       Leo Bicknell - bickn...@ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>



-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Leo Bicknell]

In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote:
> The solution here, and one that is already being worked on by vendors,
> is RA gaurd, not changing DHCPv6 in an effort to bypass RA.

Port based solutions don't work well on wireless networks and other
mediums.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpdNPR62fPVP.pgp
Description: PGP signature

RE: IPv6 Deployment for the LAN

[Tony Hain]

David Conrad wrote:
> > Ok, lets start with not breaking the functionality we have today
> > in IPv4.  Once you get that working again we can look at new
> > ideas (like RA) that might have utility. Let the new stuff live/die
> on
> > it's own merits.  The Internet is very good at sorting out the useful
> > technology from the crap.
> 
> Right.  I'll admit some confusion here.  If the IETF, due to religion
> or aesthetics, is blocking attempts at making DHCPv6 do what network
> operators _need_ (as opposed to want), why haven't network operators
> routed around the problem and gone and funded folks like ISC,
> NLNetLabs, Cisco, Juniper, et al., to implement what they need?
> 
> > At conferences I keep hearing "It would be great if the IETF had
> > more operator input."  Yet whenever we try to provide operationally
> > useful advice we are ridiculed for not being smart enough to know
> > how things should work.
> >
> > How do we fix that?
> 
> You seem to be asking "how do we make people not stupid".  Folks tend
> to simplify reality so that it fits their world view.  Stupid people
> attempt to force that simplified reality onto others.  You can either
> play their game, attempting to get them to understand reality is often
> more complicated than we'd like, or route around them.  Or you can post
> to NANOG... :-)


The root of the argument I see in this entire thread is the assumption that
'what we have for IPv4 has *always* been there'. There is lots of finger
pointing at the IETF for failure to define 15 years ago, what we have
evolved as the every-day assumptions about the IPv4 network of today. SLAAC
was presented specifically to deal with the DHCP failure modes of the time,
and the very real possibility that DHCP might not make it as a technology
that operators would want to deploy. While lots of evolution happened in the
DHCP space to deal with changing operational requirements, it is still a
complex approach (which may be why it is favored by those that like to
maintain a high salary).  To be fair, there were failures in the IETF, as
the SLAAC and DCHP sides couldn't get out of each other's way; so now
instead of having 2 independent models for provisioning, we have 2
interdependent models. RFC 5006 is one step at breaking that
interdependence, and more are needed on the DHCPv6 side, yet these steps
can't happen if people sit in the corner and do the 'they won't listen to
me' routine. 

For those that insist that DHCP is 'the only way to know who is using an
address', have you considered dDNS? Oh wait, that moves the trust point to a
different service that in the enterprise is typically run by the host admin,
not the network admin, or in the SP case crosses the trust boundary in the
wrong direction ... my bad. Seriously, there are ways to figure this out, as
Ron Broersma pointed out on Monday. I am not arguing for one model over the
other, as they each have their benefits and trade-offs. The real issue here
is that some people are so locked into one approach that they refuse to even
consider that there might be an alternative way to achieve the same goal, or
that the actual goal will change over time in the face of external
requirements. 

IPv4 continues to be a work-in-progress 30 years later, and IPv6 will be no
different. The fact that there is not functional parity between the
operational aspects is due to operators insisting until very recently that
'the only thing that matters is IPv4'. It should not be a surprise that IPv4
is where the majority of the work in the IETF happened. Despite my attempts
to get the IETF to stop wasting effort on what is clearly a dead-end, this
is still true today. As drc points out, you can continue to post complaints
on the nanog list, or if you want real change make sure your vendors get a
clear message about IPv6 being the priority, then make your point on the
appropriate IETF WG list.

At the end of the day, the way networks are operated today is not the way
they will be operated in 5 years, just as it is not the same as they way
they were operated 5 year ago. Asserting a snap-shot perspective about
'requirements' has its place, but everyone needs to recognize that this is
an evolving environment. Changing the base protocol version is just one more
step on that evolutionary path. 

Tony

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Ray Soucy]

Sorry, not buying it.

The solution here, and one that is already being worked on by vendors,
is RA gaurd, not changing DHCPv6 in an effort to bypass RA.

What your proposing as a solution isn't much of a solution at all but
just a (seemingly) lesser problem.

On Thu, Oct 22, 2009 at 3:29 PM, Leo Bicknell  wrote:
> In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy 
> wrote:
>> If the argument against RA being used to provide gateway information
>> is "rogue RA," then announcing gateway information though the use of
>> DHCPv6 doesn't solve anything.  Sure you'll get around rogue RA, but
>> you'll still have to deal with rogue DHCPv6.  So what is gained?
>
> It's a huge difference, and any conference network shows it.
>
> Let's assume 400 people come into a room, get up and working (with
> DHCPv4, and IPv6 RA's).
>
> Someone now introduces a rogue IPv4 server.  Who breaks?  Anyone who
> requests a new lease.  That is 400 people keep working just fine.
>
> Now, someone introduces a roge RA.  Who breaks?  All 400 users are
> instantly down.
>
> More importantly, there is another class of misconfigured device.  I
> plugged in a Cisco router to download new code to it on our office
> network.  It had a DHCP forward statement, and IPv6.  It was from
> another site.
>
> The DHCP forward didn't work, it pointed to something non-existant that
> also was never configured for the local subnet.  There was zero chance
> of IPv4 interfearance.
>
> The IPv6 network picked up the RA to a router with no routes though, and
> so simply plugging in the old router took down the entire office
> network.
>
> The operational threats of a DHCP based network and a RA based network
> are quite different.  Try it on your own network.
>
> --
>       Leo Bicknell - bickn...@ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>



-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Leo Bicknell]

In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote:
> If the argument against RA being used to provide gateway information
> is "rogue RA," then announcing gateway information though the use of
> DHCPv6 doesn't solve anything.  Sure you'll get around rogue RA, but
> you'll still have to deal with rogue DHCPv6.  So what is gained?

It's a huge difference, and any conference network shows it.

Let's assume 400 people come into a room, get up and working (with
DHCPv4, and IPv6 RA's).  

Someone now introduces a rogue IPv4 server.  Who breaks?  Anyone who
requests a new lease.  That is 400 people keep working just fine.

Now, someone introduces a roge RA.  Who breaks?  All 400 users are
instantly down.

More importantly, there is another class of misconfigured device.  I
plugged in a Cisco router to download new code to it on our office
network.  It had a DHCP forward statement, and IPv6.  It was from
another site.

The DHCP forward didn't work, it pointed to something non-existant that
also was never configured for the local subnet.  There was zero chance
of IPv4 interfearance.

The IPv6 network picked up the RA to a router with no routes though, and
so simply plugging in the old router took down the entire office
network.

The operational threats of a DHCP based network and a RA based network
are quite different.  Try it on your own network.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgptlutTow2Rl.pgp
Description: PGP signature

Re: {SPAM?} Re: IPv6 Deployment for the LAN

[Ray Soucy]

> This to me is one of the least credible claims of the RA/SLAAC crowd.
> On the one hand we have carriers around the world with millions and
> millions of customers getting default routes and other config through
> DHCPv4 every day. And most of the time it actually works very well!
>
> On the other hand we have RA/SLAAC with a vastly smaller customer
> base, vastly less real life testing - but which is still claimed to
> be so much better that DHCPv6 is not *allowed* to get a default route
> option.

If the argument against RA being used to provide gateway information
is "rogue RA," then announcing gateway information though the use of
DHCPv6 doesn't solve anything.  Sure you'll get around rogue RA, but
you'll still have to deal with rogue DHCPv6.  So what is gained?

I guess I'm not really seeing the case here.  Are people really making
use of DHCP to provide hosts on the same network with different
default gateway information?  If so, why?

Or is it that you want IPv6 to be a 128-bit version of IPv4?  RA is a
good idea and it works.  You can add options to DHCPv6, but I don't
see many vendors implementing default gateway support unless you can
make a real case for it.

My fear is that your goal is to do away with RA completely and turn to
DHCPv6 for all configuration.  RA is actually quite nice.  You really
need to stop fighting it, because it's not going away.

-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

Re: IPv6 Deployment for the LAN

[James R. Cutler]

On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote:


В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:


OK... Here's the real requirement:

Systems administrators who do not control routers need the ability in
a dynamic host configuration mechanism to
assign a number of parameters to the hosts they administer through
that dynamic configuration mechanism.  These
parameters include, but, are not limited to:

1.  Default Router
2.  DNS Resolver information
3.  Host can provide name to server so server can supply dynamic DNS
update
	4.	IP Address(es) (v4, v6, possibly multiple v6 in the case of  
things

like Shim6, etc.)
5.  NTP servers
6.  Boot server
7.  Site specific attribute/value pairs (ala DHCPv4 Options)

These assignments MUST be controlled by a server and not by the  
router

because the router is outside of the
administrative control of the Systems Administrator responsible for
the hosts being configured.




And to add a real-world case for this - two months ago at HAR (hacking
at random, a convention in the Netherlands) I was in the network team,
handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6
connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and  
at
some point we asked the question around - ok, how should we provide  
DNS

and other useful information for the V6 only people?

After a while with all the brains around, the decision was to write it
on the datenklos through the field, where people can read it and
configure it in their browsers. This would've been funny if it  
wasn't so

sad.

OTOH, for V4 everything with the DHCP worked fine (as it has always
done, even at an event of this size), as is my experience with all the
networks I've administered. Saying that DHCP doesn't work for me is
extremely weird, as to me this means someone made specific effort to
fuck it up.

Finally - we have something that works, that's called DHCP. It might  
not

be perfect, it might have some weird issues and implementations, but
it's actually making our lives easier, is tested and works. I'd love
anything that would be better, but as an option, not as the only  
choice

I have.
And it's not just the protocol that I care about. I care about that  
it's

implemented in a HOST, where I can play with the software as much as
possible, instead on a ROUTER, which is a vastly different device with
rarely-updated OS, and even in the case where they're both the same
machine(as in small office environments), they're again handled at
different layers (kernel vs userspace).
There are reasons that we're using what we're using, and not all of  
them

are "because we're masochistic idiots".


--
Regards,
Vasil Kolev


Following on the comments above:

The security domain for HOST should not overlap the security domain  
for ROUTER.


That is the primary driver of the separate administration of HOST and  
ROUTER. Heaven help us if the latest M$ virus, or even social- 
engineering distributed malware began to affect BGP!


Give the router managers the NTP server addresses and their DHCP  
forwarding list and leave them alone to produce a robust and reliable  
transport facility!


James R. Cutler
james.cut...@consultant.com

Re: IPv6 Deployment for the LAN

[Vasil Kolev]

В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:

> OK... Here's the real requirement:
> 
> Systems administrators who do not control routers need the ability in  
> a dynamic host configuration mechanism to
> assign a number of parameters to the hosts they administer through  
> that dynamic configuration mechanism.  These
> parameters include, but, are not limited to:
> 
>   1.  Default Router
>   2.  DNS Resolver information
>   3.  Host can provide name to server so server can supply dynamic 
> DNS  
> update
>   4.  IP Address(es) (v4, v6, possibly multiple v6 in the case of 
> things  
> like Shim6, etc.)
>   5.  NTP servers
>   6.  Boot server
>   7.  Site specific attribute/value pairs (ala DHCPv4 Options)
> 
> These assignments MUST be controlled by a server and not by the router  
> because the router is outside of the
> administrative control of the Systems Administrator responsible for  
> the hosts being configured.
> 


And to add a real-world case for this - two months ago at HAR (hacking
at random, a convention in the Netherlands) I was in the network team,
handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6
connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at
some point we asked the question around - ok, how should we provide DNS
and other useful information for the V6 only people?

After a while with all the brains around, the decision was to write it
on the datenklos through the field, where people can read it and
configure it in their browsers. This would've been funny if it wasn't so
sad.

OTOH, for V4 everything with the DHCP worked fine (as it has always
done, even at an event of this size), as is my experience with all the
networks I've administered. Saying that DHCP doesn't work for me is
extremely weird, as to me this means someone made specific effort to
fuck it up.

Finally - we have something that works, that's called DHCP. It might not
be perfect, it might have some weird issues and implementations, but
it's actually making our lives easier, is tested and works. I'd love
anything that would be better, but as an option, not as the only choice
I have. 
And it's not just the protocol that I care about. I care about that it's
implemented in a HOST, where I can play with the software as much as
possible, instead on a ROUTER, which is a vastly different device with
rarely-updated OS, and even in the case where they're both the same
machine(as in small office environments), they're again handled at
different layers (kernel vs userspace).
There are reasons that we're using what we're using, and not all of them
are "because we're masochistic idiots".


-- 
Regards,
Vasil Kolev


signature.asc
Description: Това е	 цифрово	 подписана	 част от	 писмото

Re: IPv6 Deployment for the LAN

[sthaug]

> > Like I said, if there's a bunch of routers announcing their presence  
> > and you want a DHCP option to provide guidance to a host as to which  
> > one to choose, that would be fine. But pointing to a potentially non- 
> > existing address in the hopes that there will magically be a router  
> > residing at that address would a serious regression in robustness.
> >
> It really isn't a serious regression in robustness in the real world.   
> It really is functioning today.  Most DHCP servers are not used to  
> shoot users in the head, despite your claims to the contrary.

This to me is one of the least credible claims of the RA/SLAAC crowd.
On the one hand we have carriers around the world with millions and
millions of customers getting default routes and other config through
DHCPv4 every day. And most of the time it actually works very well!

On the other hand we have RA/SLAAC with a vastly smaller customer
base, vastly less real life testing - but which is still claimed to
be so much better that DHCPv6 is not *allowed* to get a default route
option.

The mind boggles.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: IPv6 Deployment for the LAN

[Owen DeLong]

On Oct 22, 2009, at 8:44 AM, Iljitsch van Beijnum wrote:


On 22 okt 2009, at 17:03, Kevin Loch wrote:

If, on the other hand, the REAL desire is to have a DHCP server  
break the tie in the selection between several routers that  
advertise their presence, that wouldn't be unreasonable.



In some configurations not all hosts are supposed to use the same
router.  We need the _option_ to specify a default gateway and
have the override any RA's a host may see.


Lots of people "need" a gun. If I were living in a place where bears  
walk around loose I might "need" one, too. But most guns are used to  
shoot the owner in the foot most of the time. The world would be a  
better place without them.


As a strong proponent of the second amendment, it is now clear to me  
that we have a fundamental disagreement on how society should  
interoperate which is unlikely to ever be resolved between us.


Like I said, if there's a bunch of routers announcing their presence  
and you want a DHCP option to provide guidance to a host as to which  
one to choose, that would be fine. But pointing to a potentially non- 
existing address in the hopes that there will magically be a router  
residing at that address would a serious regression in robustness.


It really isn't a serious regression in robustness in the real world.   
It really is functioning today.  Most DHCP servers are not used to  
shoot users in the head, despite your claims to the contrary.


There is no requirement that the IETF provides all functionality  
that someone can think up. The list of desired functionality is  
infinite, and much on that list is a bad idea and/or can be  
achieved in different ways.



Ok, lets start with not breaking the functionality we have today
in IPv4. Once you get that working again we can look at new
ideas (like RA) that might have utility.


What does that have to with anything? IPv6 stateless autoconfig  
predates the widespread use of DHCPv4.


Hmmm... Perhaps you should be asking yourself why IPv6 SLAAC was not  
used as the model for address assignment in IPv4 instead of DHCPv4 in  
that case?



Let the new stuff live/die on
it's own merits.  The Internet is very good at sorting out the useful
technology from the crap.


Absolutely not. Give users the choice between something good that  
suits their needs 83% and a piece of crap tht suits their needs 84%  
and they'll choose the latter each and every time.


Yes... As well they should. Meeting their needs 84% of the time is  
actually vastly superior.


Users get to say what they need. They don't get to design the  
solution by committee any more than they get to design bridges or  
airplanes by committee, although of course they do get to choose  
which ones to use.


Depends on how you define users.  If you don't think that airlines  
have a substantial amount of technical input into how airliners are  
designed, you are vastly mistaken.



At conferences I keep hearing "It would be great if the IETF had
more operator input."  Yet whenever we try to provide operationally
useful advice we are ridiculed for not being smart enough to know
how things should work.



How do we fix that?


Tell the IETF your real requirements, don't try to do back seat  
protocol design. Protocol design is hard, the IETF gets it wrong  
most of the time (and they do better than some of their colleagues,  
still). Suggesting specific changes to a protocol as a solution to  
an unstated real requirement wastes everyone's time.


With writing, they tell you "listen when people say there is a  
problem, but ignore them when they tell you what the problem is".  
Same thing here. Users know their needs, but generally they don't  
know the best way to meet those needs.


OK... Here's the real requirement:

Systems administrators who do not control routers need the ability in  
a dynamic host configuration mechanism to
assign a number of parameters to the hosts they administer through  
that dynamic configuration mechanism.  These

parameters include, but, are not limited to:

1.  Default Router
2.  DNS Resolver information
	3.	Host can provide name to server so server can supply dynamic DNS  
update
	4.	IP Address(es) (v4, v6, possibly multiple v6 in the case of things  
like Shim6, etc.)

5.  NTP servers
6.  Boot server
7.  Site specific attribute/value pairs (ala DHCPv4 Options)

These assignments MUST be controlled by a server and not by the router  
because the router is outside of the
administrative control of the Systems Administrator responsible for  
the hosts being configured.


Owen

Re: ISP port blocking practice

[Valdis . Kletnieks]

On Thu, 22 Oct 2009 13:22:17 EDT, Zhiyun Qian said:
> Hi all,
> 
> What is the common practice for enforcing port blocking policy (or  
> what is the common practice for you and your ISP)? More specifically,  
> when ISPs try to block certain outgoing port (port 25 for instance),  
> they could do two rules:
> 1). For any outgoing traffic, if the destination port is 25, then drop  
> the packets.
> 2). For any incoming traffic, if the source port is 25, then drop the  
> packets.
> 
> Note that either of the rule would be able to block outgoing port 25  
> traffic since each rule essentially represent one direction in a TCP  
> flow. Of course, they could apply both rules. However, based on our  
> measurement study, it looks like most of the ISPs are only using rule  
> 1). Is there any particular reason why rule 1) instead of rule 2)? Or  
> maybe both?

Note that some spammers use assymetric routing with forged packets - they
spew out a stream of crafted packets from a compromised machine, showing
a different source IP.  The claimed source IP is also under the spammer's
control, and just basically has to catch the inbound SYN/ACK and forward
it to the spam-sender (and, if wanted, sink the other ACKs and forward the
SMTP replies from the server to the real sender).  So you can have a big
sending pipe that doesn't get ingress-filtered(*) sending the spam, and do the
control from a throwaway that may have a small pipe.

(*) Of course it's not ingress-filtered - if somebody is selling a spammer
a big pipe for this, they can arrange to fail to filter. ;)

The upshot is, of course, that you want to do (1) because you never actually
see the (2) packets, they're going someplace else...


pgpyweIhA1L51.pgp
Description: PGP signature

Re: ISP port blocking practice

[Antonio Querubin]

On Thu, 22 Oct 2009, Zhiyun Qian wrote:

the common practice for you and your ISP)? More specifically, when ISPs try 
to block certain outgoing port (port 25 for instance), they could do two 
rules:
1). For any outgoing traffic, if the destination port is 25, then drop the 
packets.
2). For any incoming traffic, if the source port is 25, then drop the 
packets.


Note that either of the rule would be able to block outgoing port 25 traffic 
since each rule essentially represent one direction in a TCP flow. Of course, 
they could apply both rules. However, based on our measurement study, it 
looks like most of the ISPs are only using rule 1). Is there any particular 
reason why rule 1) instead of rule 2)? Or maybe both?


Because rule 1 prevents the target server from having to respond to the 
initial connection request in the first place thereby reducing load on the 
server and reducing network traffic.  Ie. both rules prevent the 
connection but 1 stops it earlier.


Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  t...@lava.net

ISP port blocking practice

[Zhiyun Qian]

Hi all,

What is the common practice for enforcing port blocking policy (or  
what is the common practice for you and your ISP)? More specifically,  
when ISPs try to block certain outgoing port (port 25 for instance),  
they could do two rules:
1). For any outgoing traffic, if the destination port is 25, then drop  
the packets.
2). For any incoming traffic, if the source port is 25, then drop the  
packets.


Note that either of the rule would be able to block outgoing port 25  
traffic since each rule essentially represent one direction in a TCP  
flow. Of course, they could apply both rules. However, based on our  
measurement study, it looks like most of the ISPs are only using rule  
1). Is there any particular reason why rule 1) instead of rule 2)? Or  
maybe both?


Also, is it common that the rules are based on tcp flags (e.g. SYN,  
SYN-ACK)? One would think block SYN packet is good enough.


Regards.
-Zhiyun

Re: IPv6 Deployment for the LAN

[Adrian Chadd]

On Thu, Oct 22, 2009, Iljitsch van Beijnum wrote:

> What does that have to with anything? IPv6 stateless autoconfig  
> predates the widespread use of DHCPv4.

So does IPX and IPX/RIP.

Why does this thread seem to rehash some big disconnect between
academics, IETF and actual deployment-oriented people who have
a job to do?

Silly architecture groups..



Adrian
(Glad I'm not involved. I'd lose patience and punch people.)

Re: IPv6 Deployment for the LAN

[Iljitsch van Beijnum]

On 22 okt 2009, at 17:03, Kevin Loch wrote:

If, on the other hand, the REAL desire is to have a DHCP server  
break the tie in the selection between several routers that  
advertise their presence, that wouldn't be unreasonable.



In some configurations not all hosts are supposed to use the same
router.  We need the _option_ to specify a default gateway and
have the override any RA's a host may see.


Lots of people "need" a gun. If I were living in a place where bears  
walk around loose I might "need" one, too. But most guns are used to  
shoot the owner in the foot most of the time. The world would be a  
better place without them.


Like I said, if there's a bunch of routers announcing their presence  
and you want a DHCP option to provide guidance to a host as to which  
one to choose, that would be fine. But pointing to a potentially non- 
existing address in the hopes that there will magically be a router  
residing at that address would a serious regression in robustness.


There is no requirement that the IETF provides all functionality  
that someone can think up. The list of desired functionality is  
infinite, and much on that list is a bad idea and/or can be  
achieved in different ways.



Ok, lets start with not breaking the functionality we have today
in IPv4. Once you get that working again we can look at new
ideas (like RA) that might have utility.


What does that have to with anything? IPv6 stateless autoconfig  
predates the widespread use of DHCPv4.



Let the new stuff live/die on
it's own merits.  The Internet is very good at sorting out the useful
technology from the crap.


Absolutely not. Give users the choice between something good that  
suits their needs 83% and a piece of crap tht suits their needs 84%  
and they'll choose the latter each and every time.


Users get to say what they need. They don't get to design the solution  
by committee any more than they get to design bridges or airplanes by  
committee, although of course they do get to choose which ones to use.



At conferences I keep hearing "It would be great if the IETF had
more operator input."  Yet whenever we try to provide operationally
useful advice we are ridiculed for not being smart enough to know
how things should work.



How do we fix that?


Tell the IETF your real requirements, don't try to do back seat  
protocol design. Protocol design is hard, the IETF gets it wrong most  
of the time (and they do better than some of their colleagues, still).  
Suggesting specific changes to a protocol as a solution to an unstated  
real requirement wastes everyone's time.


With writing, they tell you "listen when people say there is a  
problem, but ignore them when they tell you what the problem is". Same  
thing here. Users know their needs, but generally they don't know the  
best way to meet those needs.

Re: IPv6 Deployment for the LAN

[David Conrad]

> Ok, lets start with not breaking the functionality we have today
> in IPv4.  Once you get that working again we can look at new
> ideas (like RA) that might have utility. Let the new stuff live/die on
> it's own merits.  The Internet is very good at sorting out the useful
> technology from the crap.

Right.  I'll admit some confusion here.  If the IETF, due to religion or 
aesthetics, is blocking attempts at making DHCPv6 do what network operators 
_need_ (as opposed to want), why haven't network operators routed around the 
problem and gone and funded folks like ISC, NLNetLabs, Cisco, Juniper, et al., 
to implement what they need?  

> At conferences I keep hearing "It would be great if the IETF had
> more operator input."  Yet whenever we try to provide operationally
> useful advice we are ridiculed for not being smart enough to know
> how things should work.
> 
> How do we fix that?

You seem to be asking "how do we make people not stupid".  Folks tend to 
simplify reality so that it fits their world view.  Stupid people attempt to 
force that simplified reality onto others.  You can either play their game, 
attempting to get them to understand reality is often more complicated than 
we'd like, or route around them.  Or you can post to NANOG... :-)

Regards,
-drc

Re: IPv6 Deployment for the LAN

[Kevin Loch]

Iljitsch van Beijnum wrote:

If, on the other hand, the REAL desire is to have a DHCP server break 
the tie in the selection between several routers that advertise their 
presence, that wouldn't be unreasonable.


In some configurations not all hosts are supposed to use the same
router.  We need the _option_ to specify a default gateway and
have the override any RA's a host may see.

There is no requirement that the IETF provides all functionality that 
someone can think up. The list of desired functionality is infinite, and 
much on that list is a bad idea and/or can be achieved in different ways.


Ok, lets start with not breaking the functionality we have today
in IPv4.  Once you get that working again we can look at new
ideas (like RA) that might have utility. Let the new stuff live/die on
it's own merits.  The Internet is very good at sorting out the useful
technology from the crap.

Seriously, we're all adults.  So treating us like children and taking 
away

the power tools is not appreciated.


Stop trying to break the internet and I'll treat you like an adult.


At conferences I keep hearing "It would be great if the IETF had
more operator input."  Yet whenever we try to provide operationally
useful advice we are ridiculed for not being smart enough to know
how things should work.

How do we fix that?

- Kevin

Re: ISP/VPN's to China?

[tvest]

On Oct 22, 2009, at 8:14 AM, Alexander Harrowell wrote:


On Thursday 22 October 2009 12:38:11 Chris Edwards wrote:

On Thu, 22 Oct 2009, Alex Balashov wrote:
| Understood.  I guess the angle I was going more for was:  Is this
| actually practical to do in a country with almost as many  
Internet users

| as the US has people?
|
| I had always assumed that broad policies and ACLs work in China,  
but most
| forms of DPI and traffic pattern analysis aren't practical simply  
for
| computational feasibility reasons.  Not unless the system were  
highly

| distributed.

Perhaps they only need make an example of a few, and thus introduce  
an

element of fear for everyone else.


I had always assumed that the Gt. Firewall, and especially the fake  
RST
element of it, existed precisely to let the geeks and weirdos stand  
out of the

naive traffic so they could be subjected to special treatment.

Similarly, this is the approach the Iranians seem to have taken  
after their
disputed election - although there isn't a telco monopoly, there's a  
wholesale
transit monopoly, and they just had the transit provider rate-limit  
everyone.

My understanding of this was that "normal" users would give up and do
something else, and only people who really wanted to reach the  
outside world
or each other  - i.e. potential subversives - would keep trying.  
Therefore,
not only would the volume of traffic to DPI, proxy etc be lower, but  
the

concentration of suspect traffic in it would be higher.

From this point of view, I suppose there's some value in using an  
IPSec or SSL
VPN, because that's what corporate traveller applications tend to  
use and
they'll therefore never cut it off. I mean, are you suggesting that  
the
assistant party secretary of Wuhan won't be able to log into  
CommunistSpace

(Iike Facebook with Chinese characteristics) while he's on the road?
Unthinkable!


Generally speaking, the definition of "corporate traveller  
applications" in such cases ==
"Whatever anyone tries to do from the following specific address  
ranges, which are known to be accessible exclusively inside certain  
international hotels, exclusively to users who are willing to pay the  
equivalent of 1-2 weeks of avg. local income for the privilege).


TV

Re: IPv6 Deployment for the LAN

[Nick Hilliard]

On 22/10/2009 12:49, bmann...@vacation.karoshi.com wrote:

its been a few weeks/years/minutes since I ran an exchange fabric,
but when we first turned up IPv6 - the first thing they did was try
to hand all the other routers IPv6 addresses.  that pesky RA/ND
thing... had to turn it off ...  RA preference would not work, since
there was no -pecking- order - all the routers were peers.


Bill, I am not able to look at this paragraph without being reminded of 
Charles Babbage's take on the GIGO principal:


"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into 
the machine wrong figures, will the right answers come out?' I am not able 
rightly to apprehend the kind of confusion of ideas that could provoke such 
a question."


Nick

Re: IPv6 Deployment for the LAN

[Karl Auer]

On Thu, 2009-10-22 at 14:25 +0200, Mohacsi Janos wrote:
> On Thu, 22 Oct 2009, bmann...@vacation.karoshi.com wrote:
> > I point you to a fairly common Internet architecture artifact,
> > the exchange point...  dozens of routers sharing a common
> > media for peering exchange.
> 
> And you want to use router advertisments for assigning addresses for them? 
> Huh!

You've got the wrong end of the stick. The point of this exchange was
that RA was not going to do the job.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF



signature.asc
Description: This is a digitally signed message part

Re: IPv6 internet broken, cogent/telia/hurricane not peering

[Frédéric]

yes of course, sorry my wrong use of english.


Le jeudi 22 octobre 2009 à 05:19 -0700, Owen DeLong a écrit :
> Please don't break existing connectivity in an effort to show support  
> for Hurricane.
> 
> That's going in the wrong direction and it doesn't help the users of  
> the internet, your customers,
> or ours.
> 
> Please do continue to, or start peering with Hurricane.
> 
> The internet works best when people peer. Breaking or damaging that in  
> any way is not
> helping any of our customers and it is contrary to Hurricane's desire.
> 
> We appreciate the intended message of support, but, it's most  
> important to preserve
> functionality for all of our customers.
> 
> Thanks,
> 
> Owen DeLong
> IPv6 Evangelist
> Hurricane Electric
> 
> On Oct 22, 2009, at 5:08 AM, Frédéric wrote:
> 
> >
> > please full support huricane !
> >
> > De-peer your ipv6 peering cogent/telia or max prepend it.
> >
> > !
> >
> >
> >
> >
> >
> > Le mercredi 21 octobre 2009 à 05:00 -0700, Matthew Petach a écrit :
> >> On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen  >> >wrote:
> >>
> >>> On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote:
>  And tonight we saw in public that even that path is being  
>  attempted:
> 
>  http://www.flickr.com/photos/77519...@n00/4031434206/
> 
>  (and yes, it was yummy and enjoyed by all at the peering BoF!)
> 
>  So Cogent...won't you please make nice with HE.net and get back
>  together again?   ^_^
> 
>  Matt
>  (speaking for neither party, but very happy to eat cake  
>  nonetheless)
> >>>
> >>> "Cogent Pleas IPv6"... for some reason that "cake typo" is even  
> >>> funnier
> >>> than the correct version. :)
> >>>
> >>>
> >> And now even better shots of the cake have been forthcoming from
> >> people.  :)
> >>
> >> http://www.flickr.com/photos/77519...@n00/4031195041/
> >>
> >> (I was all the way at the far other end of the room taking notes on  
> >> the
> >> laptop,
> >> so I never got to see the cake intact at all--all the photos are  
> >> from others
> >> who
> >> were closer to the cake, and got to see it in its pristine glory).
> >>
> >> Fortunately, I did get to partake in the eating of it.  ^_^
> >>
> >> Matt
> >> (This cake is great, it's so delicious and moist...*   ;)
> >>
> >>
> >>
> >> *http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html
> >>
> >
> 
> 

Re: ISP/VPN's to China?

[tvest]

On Oct 22, 2009, at 7:38 AM, Chris Edwards wrote:


On Thu, 22 Oct 2009, Alex Balashov wrote:

| Understood.  I guess the angle I was going more for was:  Is this  
actually
| practical to do in a country with almost as many Internet users as  
the US has

| people?
|
| I had always assumed that broad policies and ACLs work in China,  
but most
| forms of DPI and traffic pattern analysis aren't practical simply  
for
| computational feasibility reasons.  Not unless the system were  
highly

| distributed.

Perhaps they only need make an example of a few, and thus introduce an
element of fear for everyone else.


Not "a few," but rather quite a lot, albeit only infrequently, and at  
unpredictable intervals, with a very high inclusion/exclusion error  
rate -- an artifact of the absence clear and easily demonstrable line  
between compliance/non-compliance (which is itself an artifact of the  
内部 [internally published only] nature of many of the related rules).


http://www.usc.cuhk.edu.hk/wk_wzdetails.asp?id=2791
www.usc.cuhk.edu.hk/webmanager/wkfiles/2791_1_paper.pdf

TV

Re: IPv6 Deployment for the LAN

[trejrco]

WRT "Anycast DNS"; Perhaps a special-case of ULA, FD00::53? 

... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve 
FD00::/96 for this type of "ULA port-based anycast allocation". (16bits would 
only reach  w/o hex-conversion (if hex-converted could reserve FD00::/112 
... But would be less obvious))


Easily identified, not globally routable, can be pre-programmed in 
implementations/applications ... ?


... Just thinking 'out loud' ...
/TJ
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Perry Lorier 
Date: Fri, 23 Oct 2009 00:22:52 
To: 
Cc: 
Subject: Re: IPv6 Deployment for the LAN

bmann...@vacation.karoshi.com wrote:
> On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:
>   
>> On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote:
>>
>> 
>>> so your not a fan of the smart edge and the stupid network.
>>>   
>> I'm a fan of getting things right. A server somewhere 5 subnets away  
>> doesn't really know what routers are working on my subnet. It can take  
>> a guess and then wait for people to complain and then an admin to fix  
>> stuff if the guess is wrong, but I wouldn't call that a "smart edge".
>>
>> Always learn information from the place where it's actually known.
>> 
>
>   i'm ok w// that mindset.
>
>   one should learn routing from the router(s),
>   time from the time servers,
>   DNS from the DNS servers,
>   etc...
>
>   

I quite liked the old 
http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea.  
(tl;dr version: Have a set of well known site local anycast address for 
recursive name servers).  It has a number of nice features such as:

* since it's not in globally routable space people can't (ab)use your 
recursive name servers from outside your network. 
* you don't have to change recursive name servers when going to a 
different network -- they're the same everywhere.
* the addresses can be set as the default addresses by the OS 
manufacturer, and then don't need to be configured ever again.
* If your recursive name server becomes unreachable, broken or otherwise 
out of contact, it withdraws the address from your IGP, then since you 
can any cast these addresses, another node takes over.  Similar to the 
shared fate idea of RA's.
* You don't tie your recursive nameservers addresses to any point in the 
network, since they have their own special range, moving them, 
reshuffling them, or anything doesn't impact anything.  They don't need 
to cohabit a router sending RA's or anything odd like that.

However it has a number of obvious drawbacks, primarily amongst them 
being that it uses deprecated site local addresses.

You could imagine extending this to other services such as NTP, but I'm 
not sure that you really would want to go that far, perhaps using DNS to 
lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.

Another obvious approach might be to have a service discovery protocol 
where you send to a "service discovery" multicast group a message asking 
"wheres the nearest nameserver(s)?" then nameserver implementations 
could listen on this multicast group and reply.  Again shared fate.  
This does have the downside of people running rogue nameservers and 
needing a "ServiceDiscovery-Guard" feature for switches 

Personally I like the first option (anycast addresses) better, you can 
control who has access to your IGP and if your IGP is down, then for all 
intents and purposes your recursive nameservers are offline too :)

Re: IPv6 Deployment for the LAN

[Mohacsi Janos]

On Thu, 22 Oct 2009, bmann...@vacation.karoshi.com wrote:


On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:

On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:

If, on the other hand, the REAL desire is to have a DHCP server break
the tie in the selection between several routers that advertise their
presence, that wouldn't be unreasonable.


The RA contains a preference level... maybe that doesn't cut it if
multiple routers are sending the same preference level, but presumably
that would not happen in a well-tended network.


I point you to a fairly common Internet architecture artifact,
the exchange point...  dozens of routers sharing a common
media for peering exchange.


And you want to use router advertisments for assigning addresses for them? 
Huh!



Regards,
Janos

Re: IPv6 internet broken, cogent/telia/hurricane not peering

[Owen DeLong]

Please don't break existing connectivity in an effort to show support  
for Hurricane.


That's going in the wrong direction and it doesn't help the users of  
the internet, your customers,

or ours.

Please do continue to, or start peering with Hurricane.

The internet works best when people peer. Breaking or damaging that in  
any way is not

helping any of our customers and it is contrary to Hurricane's desire.

We appreciate the intended message of support, but, it's most  
important to preserve

functionality for all of our customers.

Thanks,

Owen DeLong
IPv6 Evangelist
Hurricane Electric

On Oct 22, 2009, at 5:08 AM, Frédéric wrote:



please full support huricane !

De-peer your ipv6 peering cogent/telia or max prepend it.

!





Le mercredi 21 octobre 2009 à 05:00 -0700, Matthew Petach a écrit :
On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen >wrote:



On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote:
And tonight we saw in public that even that path is being  
attempted:


http://www.flickr.com/photos/77519...@n00/4031434206/

(and yes, it was yummy and enjoyed by all at the peering BoF!)

So Cogent...won't you please make nice with HE.net and get back
together again?   ^_^

Matt
(speaking for neither party, but very happy to eat cake  
nonetheless)


"Cogent Pleas IPv6"... for some reason that "cake typo" is even  
funnier

than the correct version. :)



And now even better shots of the cake have been forthcoming from
people.  :)

http://www.flickr.com/photos/77519...@n00/4031195041/

(I was all the way at the far other end of the room taking notes on  
the

laptop,
so I never got to see the cake intact at all--all the photos are  
from others

who
were closer to the cake, and got to see it in its pristine glory).

Fortunately, I did get to partake in the eating of it.  ^_^

Matt
(This cake is great, it's so delicious and moist...*   ;)



*http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html

Re: ISP/VPN's to China?

[Alexander Harrowell]

On Thursday 22 October 2009 12:38:11 Chris Edwards wrote:
> On Thu, 22 Oct 2009, Alex Balashov wrote:
> | Understood.  I guess the angle I was going more for was:  Is this
> | actually practical to do in a country with almost as many Internet users
> | as the US has people?
> |
> | I had always assumed that broad policies and ACLs work in China, but most
> | forms of DPI and traffic pattern analysis aren't practical simply for
> | computational feasibility reasons.  Not unless the system were highly
> | distributed.
>
> Perhaps they only need make an example of a few, and thus introduce an
> element of fear for everyone else.

I had always assumed that the Gt. Firewall, and especially the fake RST 
element of it, existed precisely to let the geeks and weirdos stand out of the 
naive traffic so they could be subjected to special treatment. 

Similarly, this is the approach the Iranians seem to have taken after their 
disputed election - although there isn't a telco monopoly, there's a wholesale 
transit monopoly, and they just had the transit provider rate-limit everyone. 
My understanding of this was that "normal" users would give up and do 
something else, and only people who really wanted to reach the outside world 
or each other  - i.e. potential subversives - would keep trying. Therefore, 
not only would the volume of traffic to DPI, proxy etc be lower, but the 
concentration of suspect traffic in it would be higher.

From this point of view, I suppose there's some value in using an IPSec or SSL 
VPN, because that's what corporate traveller applications tend to use and 
they'll therefore never cut it off. I mean, are you suggesting that the 
assistant party secretary of Wuhan won't be able to log into CommunistSpace 
(Iike Facebook with Chinese characteristics) while he's on the road? 
Unthinkable!


signature.asc
Description: This is a digitally signed message part.

Re: IPv6 Deployment for the LAN

[Ray Soucy]

Just to clear things up, I'm not advocating the use of 80-bit
prefixes.  I was asking if they were a legitimate way to prevent SLAAC
in environments with hardware that don't support disabling the
autonomous flag for a prefix, or hosts that don't respect the
autonomous flag.  I've since done some testing in the lab, and have
found that the majority of operating systems that are still in use
respect the autonomous flag when deciding whether or not to run SLAAC
if IPv6 is implemented, so this becomes a non-issue.  I agree,
sticking with a 64-bit prefix for every network is a good thing.

SLAAC itself is also a good thing and I'm not advocating that it go
away.  I think its rather elegant and provides a lot of flexibility.
That said, DHCPv6 is also a key part of IPv6.  The fact that we have M
and O flags in RA, and the A flag in advertised prefixes is a pretty
strong signal that both stateless and stateful configuration are valid
choices for IPv6 deployment.

Adding DNS information to RA would generally be a bad idea.  There is
more to host configuration than just DNS, though DNS is the most
common.  I think that RA knows its role and archives it rather nicely.
 When you want to provide hosts with other configuration, like DNS,
you can do so making use of a lightweight implementation of DHCPv6.
In fact, most routers already support this.  The argument that
implementing DHCPv6 in the client is somehow too much work is
ridiculous.  DHCPv6 is as essential to IPv6 as ICMPv6 and MLD.  You
really shouldn't consider an implementation of IPv6 without a
functional DHCPv6 client complete.

At the same time, adding gateway information to DHCPv6 is also a bad
idea.  This is already accomplished by RA in an elegant and thoughtful
way.  This whole line of thinking is a result of the mindset that
SLAAC and DHCPv6 are mutually exclusive; they're not.  RA, SLAAC, and
DHCPv6 compliment one another.  They are all important components of
the IPv6 addressing architecture.

What we have now generally works well.  Getting vendors to work
together and actually implement things the same way is sometimes a
challenge.  Perhaps we need to update the language on RFCs from MAY
and SHOULD to MUST and eliminate the ambiguity of what needs to be
implemented with IPv6.

In an enterprise environment, SLAAC has no place.  It makes perfect
sense to not run SLAAC on prefixes you advertised in this case.  Just
because SLAAC is the default doesn't mean it's the only method of
deployment.  There are still some challenges to work out with DHCPv6
implementations, and it may help dual-stack environments if DHCPv6 is
amended to include a MAC address in requests when running on a
dual-stack network so associations can be made between IP and IPv6
addresses on a host, but the use of DUID is generally a good thing.
Once we start seeing more IPAM solutions include support for IPv6 and
DHCPv6 I think a lot of the hostility towards DHCPv6 will go away.

We've been implementing DHCPv6 support in our home-grown IPAM solution
and have found that it all works rather nicely.  Mac OS X is a
challenge since it doesn't provide a DHCPv6 client, but our position
has become that of saying we don't roll out IPv6 to clients with
incomplete implementations and to leave it at that.

IPv6 isn't quite necessary for all clients just yet.  There is very
little that is reachable by IPv6 only.  Until that changes, we're
willing to ignore certain groups of clients in an effort to pressure
vendors to come into the fold and support DHCPv6 by default.  If we
have a case where there is a legitimate need for IPv6, we still have
the ability to manually assign an IPv6 address on the host, but this
would be on a very limited basis.

If you're an ISP and deploying IPv6 for your residential customers, by
all means run SLAAC.  It's easy and it works.  If you manage an
enterprise IT environment and need control over your network, disable
SLAAC and run DHCPv6.  This will allow you to roll out IPv6 at your
own pace, giving you time to make sure that hosts and users are
prepared for it, all while maintaining the benefits of DHCPv6 in your
architecture.

That's all I'm trying to say.

-- 

Ray Soucy
Communications Specialist

+1 (207) 561-3526

Communications and Network Services

University of Maine System
http://www.maine.edu/

Re: IPv6 internet broken, cogent/telia/hurricane not peering

[Frédéric]

please full support huricane !

De-peer your ipv6 peering cogent/telia or max prepend it.

!





Le mercredi 21 octobre 2009 à 05:00 -0700, Matthew Petach a écrit :
> On Wed, Oct 21, 2009 at 12:13 AM, Richard A Steenbergen 
> wrote:
> 
> > On Tue, Oct 20, 2009 at 10:53:17PM -0700, Matthew Petach wrote:
> > > And tonight we saw in public that even that path is being attempted:
> > >
> > > http://www.flickr.com/photos/77519...@n00/4031434206/
> > >
> > > (and yes, it was yummy and enjoyed by all at the peering BoF!)
> > >
> > > So Cogent...won't you please make nice with HE.net and get back
> > > together again?   ^_^
> > >
> > > Matt
> > > (speaking for neither party, but very happy to eat cake nonetheless)
> >
> > "Cogent Pleas IPv6"... for some reason that "cake typo" is even funnier
> > than the correct version. :)
> >
> >
> And now even better shots of the cake have been forthcoming from
> people.  :)
> 
> http://www.flickr.com/photos/77519...@n00/4031195041/
> 
> (I was all the way at the far other end of the room taking notes on the
> laptop,
> so I never got to see the cake intact at all--all the photos are from others
> who
> were closer to the cake, and got to see it in its pristine glory).
> 
> Fortunately, I did get to partake in the eating of it.  ^_^
> 
> Matt
> (This cake is great, it's so delicious and moist...*   ;)
> 
> 
> 
> *http://www.lyricsmode.com/lyrics/e/ellen_mclain/still_alive.html
> 

Re: IPv6 Deployment for the LAN

[Karl Auer]

On Thu, 2009-10-22 at 11:30 +, bmann...@vacation.karoshi.com wrote:
> > But my question was not about IPv6. How do IPv4 routers operate in such
> > a situation?
>   exchange design 101.

Thanks :-)

I was being a bit Socratic. In the IPv4 world, routers in such complex
environments are generally manually configured. In other situations they
might use a routing protocol. Turning off RA in a similar environment
with IPv6 is no loss over IPv6.

My point (several messages ago,now) was in regard to DHCP information
being used to send preferred route information; seems to me that in a
situation where RA preference levels are not cutting it, a DHCP server
sending discrimination information is probably not going to cut it
either.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF



signature.asc
Description: This is a digitally signed message part

Fwd: [IP] [warning: layer 8/9] "Strange bedfellows, " aka a joint statement from Verizon Wireless and Google

[tvest]

Interesting, curious... but meaningful?

To my mind Google's language seems to be focused on wireline issues,  
which I guess are probably quite a bit easier for Verizon Wireless to  
accommodate.
Conversely, VW's emphasis on continuing self-regulation of wireless  
access would seem to be of secondary importance, at best, to Google.


Does this mean that a future of combat over "my (TCP) ports" is  
somewhat less likely?
Does this mean that Google won't be offering me FTTH within the next  
2-3 years?


Inquiring minds take note!

TV

Begin forwarded message:


From: David Farber 
Date: October 22, 2009 7:27:48 AM EDT
To: "ip" 
Subject: [IP] Finding Common Ground on an Open Internet -  a joint  
statement from Lowell McAdam, CEO Verizon Wireless and Eric Schmidt,  
CEO Google.

Reply-To: d...@farber.net

A Technology and Telecommunications Policy Blog
Thursday, October 22, 2009

Finding Common Ground on an Open Internet

The following is a joint statement from Lowell McAdam, CEO Verizon  
Wireless and Eric Schmidt, CEO Google.



Verizon and Google might seem unlikely bedfellows in the current  
debate

around network neutrality, or an open Internet. And while it's true we
do disagree quite strongly about certain aspects of government  
policy in

this area--such as whether mobile networks should even be part of the
discussion--there are many issues on which we agree. For starters we
both think it's essential that the Internet remains an unrestricted  
and

open platform--where people can access any content (so long as it's
legal), as well as the services and applications of their choice.



There are two key factors driving innovation on the web today. First  
is
the programming language of the Internet, which was designed over  
forty

years ago by engineers who wanted the freedom to communicate from any
computer, anywhere in the world. It enables Macs to talk to PCs,
Blackberry Storms to iPhones, the newest computers to the oldest
hardware on the planet across any kind of network--cable, DSL, fiber,
mobile, WiFi or even dial up.



Second, private investment is dramatically increasing broadband  
capacity
and the intelligence of networks, creating the infrastructure to  
support

ever more sophisticated applications.



As a result, however or wherever you access the Internet the people  
you

want to connect with can receive your message. There is no central
authority that can step in and prevent you from talking to someone  
else,

or that imposes rules prescribing what services should be available.



Transformative is an over-used word, especially in the tech sector.  
But

the Internet has genuinely changed the world. Consumers of all stripes
can decide which services they want to use and the companies they  
trust
to provide them. In addition, if you're an entrepreneur with a big  
idea,
you can launch your service online and instantly connect to an  
audience

of billions. You don't need advance permission to use the network.  At
the same time, network providers are free to develop new applications,
either on their own or in collaboration with others.



This kind of "innovation without permission" has changed the way we do
business forever, fueling unprecedented collaboration, creativity and
opportunity. And because America has been at the forefront of most of
these changes, we have disproportionately benefited in terms of  
economic

growth and job creation.



So, in conjunction with the Federal Communications Commission's  
national
plan to bring broadband to all Americans, we understand its decision  
to
start a debate about how best to protect and promote the openness of  
the

Internet. FCC Chairman Julius Genachowski has promised a thoughtful,
transparent decision-making process, and we look forward to taking  
part

in the analysis and discussion that is to follow. We believe this kind
of process can work, because as the two of us have debated these  
issues

we have found a number of basic concepts to agree on.



First, it's obvious that users should continue to have the final say
about their web experience, from the networks and software they use,  
to

the hardware they plug in to the Internet and the services they access
online. The Internet revolution has been people powered from the very
beginning, and should remain so. The minute that anyone, whether from
government or the private sector, starts to control how people use the
Internet, it is the beginning of the end of the Net as we know it.



Second, advanced and open networks are essential to the future
development of the Web. Policies that continue to provide incentives  
for

investment and innovation are a vital part of the debate we are now
beginning.



Third, the FCC's existing wireline broadband principles make clear  
that

users are in charge of all aspects of their Internet experience--from
access to apps and content. So we think it makes sense for the
Commission to establish that these existing principles are  
enf

Re: IPv6 Deployment for the LAN

[sthaug]

> > I point you to a fairly common Internet architecture artifact,
> > the exchange point...  dozens of routers sharing a common
> > media for peering exchange.
> 
> Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance 
> to an IXP?  Being one of these "artefact" operators - and clearly stuck 
> with a very small dinosaur brain - I am having some trouble understanding 
> the point you're attempting to make here.

IPv6 ND is relevant, obviously. RA, DHCP or DHCPv6 are not relevant here.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: IPv6 Deployment for the LAN

[Owen DeLong]

On Oct 22, 2009, at 2:40 AM, Iljitsch van Beijnum wrote:


On 21 okt 2009, at 22:48, Owen DeLong wrote:

The assumption that the router "knows" it is correct for every host  
on a given

LAN simply does not map to reality deployed today.


What I'm saying is that a router knows whether it's a router or not.  
A DHCP server does not, so it has to make a leap of faith and then  
sometimes the hosts fall flat on their face if there's no router on  
the address indicated by the DHCP server. The counter-argument is  
"it works today" but my counter-counter-argument is "it doesn't work  
today". I get burned by broken DHCP setups _all_ _the_ _time_ at  
work, at IETF meetings, at RIPE meetings, etc.


And what I'm saying is that knowing you are a router is not  
sufficient.  A badly configured router will mess things up just as bad  
as a badly configured DHCP server.


Anyone claiming that having a DHCP server direct hosts to a router  
address in the blind is simply incompetetent, so there is no point  
in listening to them.



The arrogance is just astounding.

If, on the other hand, the REAL desire is to have a DHCP server  
break the tie in the selection between several routers that  
advertise their presence, that wouldn't be unreasonable.


The real desire is to have the ability for the group that administers  
hosts to retain authority over host configuration. Often, in the real  
world, this is not the same group as the group that manages the  
routers. There are many different reasons that some organizations  
consider this important. Strangely, despite your claim that all of  
these people are incompetent, their IPv4 networks continue to operate  
just fine.



Please explain to me how I can achieve this functionality in RA/SLAAC
or stop pushing to prevent it from being available in DHCPv6.


There is no requirement that the IETF provides all functionality  
that someone can think up. The list of desired functionality is  
infinite, and much on that list is a bad idea and/or can be achieved  
in different ways.


Sure, but, if we want people to accept IPv6, then, it needs to, at a  
bare minimum, provide feature parity with IPv4 in addition to at least  
the advantage of a larger address space.  If it contains additional  
features, that's great.  So far, it falls short at least in this area.


Hoping not to open an additional can of worms, but, I do limit this to  
FEATURE parity, so, for example, bugs like NAT do not need to be  
replicated.  Stateful inspection and stateful inspection firewalls  
that fail closed are needed, but, the protocol gives us everything we  
need to make that work, it's a software development issue at this  
point.  NAT is strictly a kludge on top of stateful inspection which  
automatically fails closed and thus has gained the illusion of being a  
security tool in IPv4 because many people cannot distinguish the two.


Seriously, we're all adults.  So treating us like children and  
taking away

the power tools is not appreciated.


Stop trying to break the internet and I'll treat you like an adult.



And now, even more astounding arrogance.

No one is trying to break the internet.  People are, on the other  
hand, insisting that they retain certain capabilities to administer  
their own networks in the way THEY consider best, regardless of your  
arrogant idea of how they SHOULD administer their networks. Since  
their networks are working today in the manner they describe in IPv4,  
I can not accept your argument that their networks are broken.  
Further, the idea that it is possible to "break the internet" by  
giving administrators the option to assign router information from a  
DHCP server is simply absurd.


Owen

Re: IPv6 Deployment for the LAN

[bmanning]

On Thu, Oct 22, 2009 at 12:35:18PM +0100, Nick Hilliard wrote:
> On 22/10/2009 11:30, bmann...@vacation.karoshi.com wrote:
> >On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:
> >>The RA contains a preference level... maybe that doesn't cut it if
> >>multiple routers are sending the same preference level, but presumably
> >>that would not happen in a well-tended network.
> >
> > I point you to a fairly common Internet architecture artifact,
> > the exchange point...  dozens of routers sharing a common
> > media for peering exchange.
> 
> Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance 
> to an IXP?  Being one of these "artefact" operators - and clearly stuck 
> with a very small dinosaur brain - I am having some trouble understanding 
> the point you're attempting to make here.
> 
> Nick


its been a few weeks/years/minutes since I ran an exchange fabric,
but when we first turned up IPv6 - the first thing they did was try
to hand all the other routers IPv6 addresses.  that pesky RA/ND
thing... had to turn it off ...  RA preference would not work, since
there was no -pecking- order - all the routers were peers.

we did the manual configuration - no DHCP - it was the only way to
ensure things would be deterministic.  Hence my comments to 
Karl re his statement about "not happen in a well-tended network".

the point.  RA/ND was designed to solve what some of its designers
thought would be 80% of the problems.  It might just be able to 
do that - for the limited scope that it has.  There are other, more
robust, decomposable, resilient configuration tools out there that
have capabilities people need that are not currently in RA/ND.

and even then, not all architectures are ammenable to automated 
configuration tools.

RA/ND is not a panecea.  

--bill

Re: IPv6 Deployment for the LAN

[bmanning]

On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote:
> 
> You could imagine extending this to other services such as NTP, but I'm 
> not sure that you really would want to go that far, perhaps using DNS to 
> lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.
> 
> Another obvious approach might be to have a service discovery protocol 
> where you send to a "service discovery" multicast group a message asking 
> "wheres the nearest nameserver(s)?" then nameserver implementations 
> could listen on this multicast group and reply.  Again shared fate.  
> This does have the downside of people running rogue nameservers and 
> needing a "ServiceDiscovery-Guard" feature for switches 

ah... well - if your a router centric person, then you want
to put everything into the tools you know and love.

if your a dns centric person, then you put everything in the
DNS.

I point you to the "DISCOVER' opcode (experimental) in the DNS
and the use of DNS over multicast for doing service discovery
(e.g. Apples Bonjour)...  Most of that is already designed/deployed
and in pretty widespread use... over IPv4 or IPv6.

And yes, its not RA/ND, or DHCP... its another configuration protocol
and its not quite vendor specific.  The best thing is, it pushes
the smarts closer to the edge (the end device)  and this makes me happy.

> Personally I like the first option (anycast addresses) better, you can 
> control who has access to your IGP and if your IGP is down, then for all 
> intents and purposes your recursive nameservers are offline too :)
> 

everyone to their own taste.

--bill

Re: ISP/VPN's to China?

[Chris Edwards]

On Thu, 22 Oct 2009, Alex Balashov wrote:

| Understood.  I guess the angle I was going more for was:  Is this actually
| practical to do in a country with almost as many Internet users as the US has
| people?
| 
| I had always assumed that broad policies and ACLs work in China, but most
| forms of DPI and traffic pattern analysis aren't practical simply for
| computational feasibility reasons.  Not unless the system were highly
| distributed.

Perhaps they only need make an example of a few, and thus introduce an 
element of fear for everyone else.

Re: IPv6 Deployment for the LAN

[Nick Hilliard]

On 22/10/2009 11:30, bmann...@vacation.karoshi.com wrote:

On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:

The RA contains a preference level... maybe that doesn't cut it if
multiple routers are sending the same preference level, but presumably
that would not happen in a well-tended network.


I point you to a fairly common Internet architecture artifact,
the exchange point...  dozens of routers sharing a common
media for peering exchange.


Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance 
to an IXP?  Being one of these "artefact" operators - and clearly stuck 
with a very small dinosaur brain - I am having some trouble understanding 
the point you're attempting to make here.


Nick

Re: IPv6 Deployment for the LAN

[bmanning]

On Thu, Oct 22, 2009 at 10:18:48PM +1100, Karl Auer wrote:
> On Thu, 2009-10-22 at 11:08 +, bmann...@vacation.karoshi.com wrote:
> > On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote:
> > > On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote:
> > > > > The RA contains a preference level... maybe that doesn't cut it if
> > > > 
> > > > I point you to a fairly common Internet architecture artifact,
> > > > the exchange point...  dozens of routers sharing a common
> > > > media for peering exchange.  
> > > 
> > > And how do they discriminate now, with IPv4?
> >
> > IPv4 has no concept of RA/ND.  to make this construct work at
> > all in IPv6, all participants have to turn -off-  RA/ND to prevent
> > one or more routers trying to impose their views of addressing
> > on their neighbours.
> 
> But my question was not about IPv6. How do IPv4 routers operate in such
> a situation?
> 
> Regards, K.
> 

exchange design 101.

each connecting router interface is manually configured with an
address of the exchange fabrics IP space.

to establish peering, a router needs to know, at a minimum, the targets
IP address and ASN - and while arp (if enabled) can get the target IP 
address,
the ASN has to come via another channel - usually manually aquired.

this is how the exchanges generally work, regardless of IP address 
family.

more generally, where there are two or more egress routers from a 
broadcast
domain, there will be problems -if- the routers know about each other 
-and-
have the ability to try and set the exit rules for all other 
participants
sharing the broadcast domain.  Hence, with IPv6 and RA/ND, the idea of 
"preference" levels ... although in most cases I've experienced where 
there 
are multiple exit routers - that doesn't work either, since only 
subsets of 
the nodes on the shared media can use one or the other egress router.  
e.g.
all the nodes don't fate-share.

RA/ND was only an 80% solution anyway.  
--bill

Re: Consistent asymetric latency on monitoring?

[Rick Ernst]

Lots of good info, and a nice mind-dump that gives me a whole host of other
things that need to be looked at... Umm. "thanks" :)

On Wed, Oct 21, 2009 at 11:10 PM, Perry Lorier  wrote:

> Rick Ernst wrote:
>
>> Resent, since I responded from the wrong address:
>> ---
>> The basic operation of IP SLA is as surmised; payload with timestamps
>> and other telemetry data is sent to a 'responder' which manipulates
>> the payload, including adding its own timestamps, and returns the
>> altered payload.
>>
>>
>
> Yup :) It's the obvious way to do it :)
>
>  I had to do a mental walk-through, but I think I see how drift can
>> cause this. I'm going to generate some artificial data, graph it, and
>> see if it matches the general waveshape I'm seeing.
>>
>> I purposefully have the traffic generators ntp syncing against the
>> responders. I thought that would keep the clocks more closely in sync.
>> I don't necessarily care if the time is 'right', just that it's the
>> same.
>>
>
> This causes major problems.  What you're actually measuring here is how
> well ntp can keep the clock sync'd under assymetric latency.  ntp is trying
> to do it's own measurements of one way delay, without the help of clocks to
> measure clock drift as well.   As you can see from your graphs ntp is not
> coping[1].
>
> You are far better to have each end sync to a local stratum 1 or stratum 2
> ntp source, preferably one over a different link to the one under test.  If
> you don't have a local stratum 1/2 time source at each end,  you might be
> able find one over a local exchange or other less congested link.  If this
> is very important to you then you should consider looking at running your
> own stratum 1 clocks at each end syncronised off something like GPS, CDMA or
> a T1 clock.
>
>  What kind of difference should I expect if I sync both
>> generators and responders against the same source, or not sync the
>> responder? I'm thinking that having one source with constant drift may
>> be better than both devices trying to walk/correct the time.
>>
>>
>
> Most hardware clocks in PC's/routers/switches etc have pretty atrocious
> amounts of drift if left to free run[2], sometimes in the order of seconds
> or occasionally minutes per week.  To get useful numbers you really do need
> to syncronise them to /something/.  Synchronising them to each other causes
> problems as ntp I think (I could be wrong) assumes mostly symmetrical
> latency, and if the latency isn't symmetric assumes it's because one clock
> is running fast/slow and will alter the clock's speed to account for it.
>  The great thing about ntp stratum 1 servers is that by definition they have
> more or less the same time no matter where they are, so synchronising each
> against a local ntp server will be a much much better solution.  If possible
> you should consider peering with at least 3 upstreams, preferably 4(!)[3]
> other ntp servers.
>
> [1]: To be fair it's a hard problem.  Anything that involves time just gets
> more and more complicated the more you look at it, ntp is extremely clever
> and probably knows more about time than I'd ever want to know, but you're
> making it's job hard.
>
> [2]: http://vancouver-webpages.com/time/ /
> http://vancouver-webpages.com/time/ltmhist.png
>
> [3]:
> http://twiki.ntp.org/bin/view/Support/SelectingOffsiteNTPServers#Section_5.3.3
> .
>

Re: IPv6 Deployment for the LAN

[Perry Lorier]

bmann...@vacation.karoshi.com wrote:

On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:
  

On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote:



so your not a fan of the smart edge and the stupid network.
  
I'm a fan of getting things right. A server somewhere 5 subnets away  
doesn't really know what routers are working on my subnet. It can take  
a guess and then wait for people to complain and then an admin to fix  
stuff if the guess is wrong, but I wouldn't call that a "smart edge".


Always learn information from the place where it's actually known.



i'm ok w// that mindset.

one should learn routing from the router(s),
time from the time servers,
DNS from the DNS servers,
etc...

  


I quite liked the old 
http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea.  
(tl;dr version: Have a set of well known site local anycast address for 
recursive name servers).  It has a number of nice features such as:


* since it's not in globally routable space people can't (ab)use your 
recursive name servers from outside your network. 
* you don't have to change recursive name servers when going to a 
different network -- they're the same everywhere.
* the addresses can be set as the default addresses by the OS 
manufacturer, and then don't need to be configured ever again.
* If your recursive name server becomes unreachable, broken or otherwise 
out of contact, it withdraws the address from your IGP, then since you 
can any cast these addresses, another node takes over.  Similar to the 
shared fate idea of RA's.
* You don't tie your recursive nameservers addresses to any point in the 
network, since they have their own special range, moving them, 
reshuffling them, or anything doesn't impact anything.  They don't need 
to cohabit a router sending RA's or anything odd like that.


However it has a number of obvious drawbacks, primarily amongst them 
being that it uses deprecated site local addresses.


You could imagine extending this to other services such as NTP, but I'm 
not sure that you really would want to go that far, perhaps using DNS to 
lookup "_ntp._udp.local IN SRV" or similar to find your local NTP servers.


Another obvious approach might be to have a service discovery protocol 
where you send to a "service discovery" multicast group a message asking 
"wheres the nearest nameserver(s)?" then nameserver implementations 
could listen on this multicast group and reply.  Again shared fate.  
This does have the downside of people running rogue nameservers and 
needing a "ServiceDiscovery-Guard" feature for switches 

Personally I like the first option (anycast addresses) better, you can 
control who has access to your IGP and if your IGP is down, then for all 
intents and purposes your recursive nameservers are offline too :)

Re: IPv6 Deployment for the LAN

[Karl Auer]

On Thu, 2009-10-22 at 11:08 +, bmann...@vacation.karoshi.com wrote:
> On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote:
> > On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote:
> > > > The RA contains a preference level... maybe that doesn't cut it if
> > > 
> > >   I point you to a fairly common Internet architecture artifact,
> > >   the exchange point...  dozens of routers sharing a common
> > >   media for peering exchange.  
> > 
> > And how do they discriminate now, with IPv4?
>
>   IPv4 has no concept of RA/ND.  to make this construct work at
>   all in IPv6, all participants have to turn -off-  RA/ND to prevent
>   one or more routers trying to impose their views of addressing
>   on their neighbours.

But my question was not about IPv6. How do IPv4 routers operate in such
a situation?

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF



signature.asc
Description: This is a digitally signed message part

Re: IPv6 Deployment for the LAN

[bmanning]

On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote:
> On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote:
> > > The RA contains a preference level... maybe that doesn't cut it if
> > > multiple routers are sending the same preference level, but presumably
> > > that would not happen in a well-tended network.
> > 
> > I point you to a fairly common Internet architecture artifact,
> > the exchange point...  dozens of routers sharing a common
> > media for peering exchange.  
> 
> And how do they discriminate now, with IPv4?
> 
> Regards, K.
> 

IPv4 has no concept of RA/ND.  to make this construct work at
all in IPv6, all participants have to turn -off-  RA/ND to prevent
one or more routers trying to impose their views of addressing
on their neighbours.

--bill

Re: Consistent asymetric latency on monitoring?

[Roland Dobbins]

On Oct 21, 2009, at 11:03 PM, Rick Ernst wrote:

 I thought that would keep the clocks more closely in sync.  I don't  
necessarily care if the time is 'right', just that it's the same.


ntp is a pretty basic operational requirement for any network,  
irrespective of the use of IP SLA, is it not?


---
Roland Dobbins  // 

Sorry, sometimes I mistake your existential crises for technical
insights.

-- xkcd #625

Re: IPv6 Deployment for the LAN

[Karl Auer]

On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote:
> > The RA contains a preference level... maybe that doesn't cut it if
> > multiple routers are sending the same preference level, but presumably
> > that would not happen in a well-tended network.
> 
>   I point you to a fairly common Internet architecture artifact,
>   the exchange point...  dozens of routers sharing a common
>   media for peering exchange.  

And how do they discriminate now, with IPv4?

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF



signature.asc
Description: This is a digitally signed message part

Re: IPv6 Deployment for the LAN

[bmanning]

On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote:
> On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
> > If, on the other hand, the REAL desire is to have a DHCP server break  
> > the tie in the selection between several routers that advertise their  
> > presence, that wouldn't be unreasonable.
> 
> The RA contains a preference level... maybe that doesn't cut it if
> multiple routers are sending the same preference level, but presumably
> that would not happen in a well-tended network.

I point you to a fairly common Internet architecture artifact,
the exchange point...  dozens of routers sharing a common
media for peering exchange.  

> 
> Regards, K.
> 

--bill

Re: IPv6 Deployment for the LAN

[bmanning]

On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote:
> On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote:
> 
> > so your not a fan of the smart edge and the stupid network.
> 
> I'm a fan of getting things right. A server somewhere 5 subnets away  
> doesn't really know what routers are working on my subnet. It can take  
> a guess and then wait for people to complain and then an admin to fix  
> stuff if the guess is wrong, but I wouldn't call that a "smart edge".
> 
> Always learn information from the place where it's actually known.

i'm ok w// that mindset.

one should learn routing from the router(s),
time from the time servers,
DNS from the DNS servers,
etc...

now -normally- I would expect the router to focus on
forwarding packets ... not be the time keeper, DNS server,
handing out IP addresses,  hosting content for the HTTP protocol etc.

sounds to me like your reacting to a particular style of 
implementation (DHCP servers being multi-hops away) and want
to move the function(s) closer to the edge, e.g. in the routers.

and if we can get RA/ND -fixed- to accomodate all the functions that
folks have grown to depend on over the years from a configuration 
service
like DHCP - then we should be able to converge.  

I am not a fan of the way DHCPv6 has developed/emerged.  And yes,
I've re-written both client and server to fix the egergious problems 
found in the current spec... (it now works just fine for doing things
like handing out DNS servers for resolvers,  picking mapped addresses
for my IVI service, etc.)   so my DHCP is non-interoperable w/ anyone
elses.

Thing is, its easier to fix DHCP code than to fix the router code.

And the edge is not the LAN, its the device.


--bill

Re: IPv6 Deployment for the LAN

[Karl Auer]

On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote:
> If, on the other hand, the REAL desire is to have a DHCP server break  
> the tie in the selection between several routers that advertise their  
> presence, that wouldn't be unreasonable.

The RA contains a preference level... maybe that doesn't cut it if
multiple routers are sending the same preference level, but presumably
that would not happen in a well-tended network.

In any case, anywhere this is actually of vital importance, a routing
protocol would be in use.

Using the DHCP protocol to deliver information - about anything really -
is what it's *for*. That said, making clients depend utterly on the
presence of a working DHCP server for basic connectivity seems like a
backward step. Of course, different people have different ideas about
what constitutes "basic" connectivity.

> Stop trying to break the internet and I'll treat you like an adult.

Whoa! Tell you what, how about if I break it, and you get to choose
which piece you keep? [Bash, bash, thud. Ugh. Hm. It's tougher than it
looks!]

:-)

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF



signature.asc
Description: This is a digitally signed message part

Re: IPv6 Deployment for the LAN

[Iljitsch van Beijnum]

On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote:


so your not a fan of the smart edge and the stupid network.


I'm a fan of getting things right. A server somewhere 5 subnets away  
doesn't really know what routers are working on my subnet. It can take  
a guess and then wait for people to complain and then an admin to fix  
stuff if the guess is wrong, but I wouldn't call that a "smart edge".


Always learn information from the place where it's actually known.

Re: IPv6 Deployment for the LAN

[Iljitsch van Beijnum]

On 21 okt 2009, at 23:34, David W. Hankins wrote:


There is a problem with the "Both RA and DHCPv6 Model" currently
proposed by IETF iconoclasts.  Should RA fail, for any reason from
router, system, software, network path, security, or user error,
then the simplest networks imaginable (where hosts and mail/Intranet/
work servers are all co-located on the same broadcast domain) will
not be able to talk to one another,


Or the rest of the world.

Note however that it is very hard to get false negatives for RAs and  
even harder to get false positives. The only way I've had RAs fail in  
the real world was with multilayer switches that wouldn't let IPv6  
multicasts through because they couldn't do IGMP snooping for those.  
This affected RAs but also all other neighbor discovery, and would  
have affected DHCPv6, too. So in this situation IPv6 is completely  
dead in the water.


The good thing is that you don't get any false positives, where a host  
thinks there's a router somewhere but there's not actually a router  
there. This is because when a router stops being a router it will also  
stop sending RAs.


All of this works extremely well, I can't think of any instance where  
there is any trouble with RAs, except of course the problem of rogue  
routers advertising themselves. However, this is not really any  
different from the situation in IPv4 where rogue DHCP servers  
advertise stuff they shouldn't advertise.



To work around this problem, some DHCPv6 software implementers have
elected to temporarily apply a fixed /64 bit prefix to all applied
addresses until a prefix length can be made available in-band through
some means.


Why not simply fix the DHCPv6 protocol so it has a prefix length  
attribute?


DHCP'ers can complain about stateless autoconfig and RAs, but the  
simple truth is that DHCPv6 has problems that are unrelated to  
anything outside DHCPv6 that haven't been fixed in the half a decade  
that I've been paying attention to it.



But it may complicate your designs if you
are assigning /80's.


RFC 3513 says that all interface identifiers for addresses outside ::/ 
3 must be 64 bits in size. That doesn't work with a /80. So I'm not  
sure if using DHCPv6 with /80s will work on all systems.



According to the release notes of ISC DHCP 4.1.0, ISC 'dhclient -6'
compiles and runs on Mac OSX.  I don't actually own a Mac, so I have
never used it myself, and our release notes even go into detail about
the limitations of the current 'dhclient-script' for the Darwin
platform (apparently their configuration system is somewhat opaque).


MacOS detects when interface go online and offline and does all kinds  
of stuff when that happens. For instance, you can't globally enable/ 
disable stateless autoconfig on MacOS, either.


Manually running a script when the interface status changes is a  
rather blunt way to interact with the system.


Does anyone know if Apple has plans to release a DHCPv6 client for  
Mac OS X?



No...but I have heard plans of the exact opposite.


[...]


When people at
the microphone asked why Apple did not include a DHCPv6 client
implementation, even a stateless one, I believe Bernard Aboba
addressed the concern at the microphone saying, and I am paraphrasing
from memory here, "We were told by the IETF that RA was all we would
ever need, implementing DHCPv6 is optional, so RA is all we are
doing."


I don't remember that. What I do remember is that Stuart Cheshire of  
Apple explained how he was unhappy that it was necessary to run a  
rather involved protocol (DHCPv6) for the relatively simple task of  
obtaining DNS resolver addresses.



To summarize, RA+DHCPv6 implementers are posed with problems:


...which apparently some DHCPv6 people want to solve by ALWAYS running  
their chatty protocol that wastes a lot of bandwidth on wireless LANs  
until people give in and just run a DHCPv6 server just to get rid of  
the constant DHCP retransmissions that can't be stopped any other way  
because actually looking at the O/M bits is of course way too simple.


I hate this crap so much.

Re: IPv6 Deployment for the LAN

[Iljitsch van Beijnum]

On 21 okt 2009, at 22:48, Owen DeLong wrote:

The assumption that the router "knows" it is correct for every host  
on a given

LAN simply does not map to reality deployed today.


What I'm saying is that a router knows whether it's a router or not. A  
DHCP server does not, so it has to make a leap of faith and then  
sometimes the hosts fall flat on their face if there's no router on  
the address indicated by the DHCP server. The counter-argument is "it  
works today" but my counter-counter-argument is "it doesn't work  
today". I get burned by broken DHCP setups _all_ _the_ _time_ at work,  
at IETF meetings, at RIPE meetings, etc.


Anyone claiming that having a DHCP server direct hosts to a router  
address in the blind is simply incompetetent, so there is no point in  
listening to them.


If, on the other hand, the REAL desire is to have a DHCP server break  
the tie in the selection between several routers that advertise their  
presence, that wouldn't be unreasonable.



Please explain to me how I can achieve this functionality in RA/SLAAC
or stop pushing to prevent it from being available in DHCPv6.


There is no requirement that the IETF provides all functionality that  
someone can think up. The list of desired functionality is infinite,  
and much on that list is a bad idea and/or can be achieved in  
different ways.


Seriously, we're all adults.  So treating us like children and  
taking away

the power tools is not appreciated.


Stop trying to break the internet and I'll treat you like an adult.

Re: ISP/VPN's to China?

[Alex Balashov]

Chris Edwards wrote:

Doesn't necessarily have to be hugely accurate.  The authorities could 
simply identify a few likely suspect tunnels, then knock-on-doors and ask 
you to explain what the traffic in question is...


Understood.  I guess the angle I was going more for was:  Is this 
actually practical to do in a country with almost as many Internet 
users as the US has people?


I had always assumed that broad policies and ACLs work in China, but 
most forms of DPI and traffic pattern analysis aren't practical simply 
for computational feasibility reasons.  Not unless the system were 
highly distributed.


--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

Re: ISP/VPN's to China?

[Chris Edwards]

On Wed, 21 Oct 2009, Alex Balashov wrote:

| I was not aware that tools or techniques to do this are widespread or highly
| functional in a way that would get them adopted in an Internet access control
| application of a national scope.

Doesn't necessarily have to be hugely accurate.  The authorities could 
simply identify a few likely suspect tunnels, then knock-on-doors and ask 
you to explain what the traffic in question is...

Re: ISP/VPN's to China?

[Seth David Schoen]

Adrian Chadd writes:

> On Wed, Oct 21, 2009, Alex Balashov wrote:
> > I was not aware that tools or techniques to do this are widespread or  
> > highly functional in a way that would get them adopted in an Internet  
> > access control application of a national scope.
> > 
> > Tell me more?
> 
> It's been a while since I tinkered with this for fun, but a quick abuse
> of google gives one relatively useful starting paper:
> 
> http://ccr.sigcomm.org/online/files/p7-v37n1b-crotti.pdf

A lot of research papers on what is or isn't possible in traffic
analysis are linked from

http://freehaven.net/anonbib/topic.html#Traffic_20analysis

This bibliography is updated periodically.  It's a pretty big, complex
topic, and the open literature could use lots more publications.

-- 
Seth David Schoen  | Qué empresa fácil no pensar en
 http://www.loyalty.org/~schoen/   | un tigre, reflexioné.
 http://vitanuova.loyalty.org/ |-- Borges, El Zahir