<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.apple-tab-span
{mso-style-name:apple-tab-span;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-AU link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Because by participating in the protocol you are indicating
adherence to the specification where as NAT is just a giant hack.<br>
<br>
<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Matthew Moyle-Croft
[mailto:mmc@internode.com.au] <br>
<b>Sent:</b> Friday, 1 August 2008 11:47 AM<br>
<b>To:</b> McDonald Richards<br>
<b>Cc:</b> 'Chris Chaundy'; ausnog@ausnog.net<br>
<b>Subject:</b> Re: [AusNOG] IPv4 Exhaustion, APNIC EC, and James is a nice
bloke ; -)<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>For Application level proxying see my comments below about
poor software and protocol implementations. Why would it be ANY better
when you're just going to see broken proxy implementations vs broken NAT vs
broken stateful firewalls.<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>MMC<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<div>
<p class=MsoNormal>On 01/08/2008, at 11:13 AM, McDonald Richards wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<p class=MsoNormal><span style='color:black'>> So application level proxying
is okay but NAT isn't? (*MMC looks around to check it's a joke
he's not in on*)<o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Normally when proxying you adhere more closely to the protocol
specifications you’re supporting rather than having to rely on port forwarding
to “fix” issues introduced by NAT. Since a proxy actually participates in
signalling, it’s less likely to cause the problems NAT does (unreachable
addresses contained inside signalling messages etc).</span><span
style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There is no reason that equipment cannot be given a global
address if required, this just allows the extra layer of security that having a
non-routable address gives us.</span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm;
border-width:initial;border-color:initial'>
<div>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:black'>From:</span></b><span
class=apple-converted-space><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif";color:black'> </span></span><span
lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:black'><a href="mailto:ausnog-bounces@ausnog.net">ausnog-bounces@ausnog.net</a><span
class=apple-converted-space> </span>[<a
href="mailto:ausnog-bounces@ausnog.net">mailto:ausnog-bounces@ausnog.net</a>]<span
class=apple-converted-space> </span><b>On Behalf Of<span
class=apple-converted-space> </span></b>Matthew Moyle-Croft<br>
<b>Sent:</b><span class=apple-converted-space> </span>Friday, 1 August
2008 11:35 AM<br>
<b>To:</b><span class=apple-converted-space> </span>Chris Chaundy<br>
<b>Cc:</b><span class=apple-converted-space> </span><a
href="mailto:ausnog@ausnog.net">ausnog@ausnog.net</a><br>
<b>Subject:</b><span class=apple-converted-space> </span>Re: [AusNOG] IPv4
Exhaustion, APNIC EC, and James is a nice bloke ; -)</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class=MsoNormal><span style='color:black'>On 01/08/2008, at 10:59 AM, Chris
Chaundy wrote:<o:p></o:p></span></p>
</div>
</div>
<div>
<p class=MsoNormal><span style='color:black'><br>
<br>
<br>
<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>It’s a while since I’ve had to deal with this, but as I understand
it, there are protocols that embed addressing and port information in payloads
which need to be fiddled if there is/are NAT(s) in the path. If the
extended address space offered by IPv6 allows us to escape from the NAT ‘functionality’
(and we just have firewall security), then there is no need for any fiddling.</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
</div>
<div>
<p class=MsoNormal><span style='color:black'>But stateful firewalls still need
to understand the protocol. Not understanding it properly still leads to
a lack of connectivity (or too much) will still means it doesn't work and leads
to problems and frustrations by the customers.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'>I'm just pointing out here that
NAT isn't the problem. It's badly written software and poorly
defined/implemented protocols no matter what shape/flavour they are.
Getting rid of NAT and using stateful firewalls just paints the fence a
different colour.<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
</div>
<div>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Of course, as Macca pointed out, proxying will probably be the way
things will go for most applications in the future anyway.</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
</div>
<div>
<p class=MsoNormal><span style='color:black'>So application level proxying is
okay but NAT isn't? (*MMC looks around to check it's a joke he's
not in on*)<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'>MMC<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
</div>
<div>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'> </span><span style='color:black'><o:p></o:p></span></p>
</div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:black'>-----Original Message-----<br>
<b>From:</b><span class=apple-converted-space> </span>Matthew Moyle-Croft
[<a href="mailto:mmc@internode.com.au">mailto:mmc@internode.com.au</a>]<span
class=apple-converted-space> </span><br>
<b>Sent:</b><span class=apple-converted-space> </span>Friday, 1 August
2008 11:07 AM<br>
<b>To:</b><span class=apple-converted-space> </span>Chris Chaundy<br>
<b>Cc:</b><span class=apple-converted-space> </span><a
href="mailto:ausnog@ausnog.net">ausnog@ausnog.net</a><br>
<b>Subject:</b><span class=apple-converted-space> </span>Re: [AusNOG] IPv4
Exhaustion, APNIC EC, and James is a nice bloke ; -)</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>Stateful firewalls (the
solution touted as required for CPE) still appear to require an understanding
of the protocols going through them - to understand the "state"
of a protocol and what connections can/should be opened up.</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>Remind me then how the
protocol tweaking will decline? </span><span style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>MMC</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>On 01/08/2008, at 10:08
AM, Chris Chaundy wrote:</span><span style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>A further comment on
this topic - I agree entire on the comments<br>
regarding accessibility versus addressability. One of the problems with<br>
NAT is all the tweaking needed for some protocols that 'break the rules'<br>
as far as layering of protocols go by embedding information about lower<br>
layers in higher layers which leads to complexity which inevitably leads<br>
to bugs.<br>
<br>
While IPv6 is may problematic for some of these protocols, it is a<br>
problem that will have to be solved, and once solved, NAT (and the<br>
tweaking) will no longer be necessary when we have sufficient address<br>
space (well in the perfect world anyway :-). Long live the KISS<br>
principle...<br>
<br>
-----Original Message-----<br>
From:<span class=apple-converted-space> </span><a
href="mailto:ausnog-bounces@ausnog.net">ausnog-bounces@ausnog.net</a><span
class=apple-converted-space> </span>[<a
href="mailto:ausnog-bounces@ausnog.net">mailto:ausnog-bounces@ausnog.net</a>]
On<br>
Behalf Of Mark Newton<br>
Sent: Friday, 1 August 2008 8:51 AM<br>
To: Robert Brockway<br>
Cc:<span class=apple-converted-space> </span><a
href="mailto:ausnog@ausnog.net">ausnog@ausnog.net</a><br>
Subject: Re: [AusNOG] IPv4 Exhaustion, APNIC EC, and James is a nice<br>
bloke ;-)<br>
<br>
<br>
On 01/08/2008, at 1:11 AM, Robert Brockway wrote:</span><span style='color:
black'><o:p></o:p></span></p>
</div>
</div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>Please excuse me if I'm
wrong but it seems like you are equating</span><span style='color:black'><o:p></o:p></span></p>
</div>
</div>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>'publically accessible'
to 'publically addressable'. They need not </span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>be the</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>same thing as per
earlier parts of the thread.</span><span style='color:black'><o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'><br>
There's a certain amount of cross-purposes discussion going on here.<br>
<br>
I don't think anyone is equating the two issues in the way you've<br>
described. It might be useful for you to assume that those in this<br>
thread who have taken a contrary view have a full and complete<br>
understanding of the problem and simply disagree with you.<br>
<br>
Let me expand on it just slightly, by way of illustration.<br>
<br>
Lets say you have some firewall code in your CPE. That's something<br>
that controls "accessibility."<br>
<br>
And lets also say you have some NAT code in your CPE. That's something<br>
that controls "addressability."<br>
<br>
Flows passing through the CPE are NAT'ed (re-addressed), and also<br>
passed through the firewall. That seems to be the typical way that<br>
most CPE works; Whether you're talking about a Cisco or a Billion,<br>
the stateful inspection configuration stanzas and internal code paths<br>
are different beasts.<br>
<br>
Now -- Lets assume you're using cheap and nasty CPE that has<br>
firmware that's of, shall we say, variable quality.<br>
<br>
If the firewall is buggy, it'll incorrectly block some traffic and<br>
incorrectly pass other traffic. The one Bevan is worried about is<br>
incorrectly passing traffic to his fridge -- i.e., making an<br>
incorrect decision about whether his fridge should be accessible.<br>
<br>
Separately:<br>
<br>
If the NAT code is buggy, it'll incorrectly translate inside<br>
addresses to outside addresses. The degenerate, almost inevitable<br>
case is that devices on the "inside" won't have an network access<br>
due to NAT bugs.<br>
<br>
Now consider each facility being present or not present individually,<br>
and consider the failure modes.<br>
<br>
In the presence of bugs on a device that has NAT and no firewall,<br>
devices inside your network won't have network access.<br>
<br>
In the presence of bugs on a device that has a firewall and no<br>
NAT, incorrect decisions regarding accessibility will be made and<br>
Bevan's fridge will conceivably be reachable from the outside.<br>
<br>
In the presence of bugs on a device that has a firewall and NAT,<br>
incorrect decisions regarding accessibility won't matter very<br>
much because nothing on the inside is addressable, or, consequently,<br>
reachable; and NAT failures will -still- cause devices inside<br>
your network to not have network access.<br>
<br>
So -- although NAT != security, what NAT *does* do is make your<br>
firewall fail-safe. The preference in the event of a bug when<br>
NAT is present is to deny access. The preference in the event of<br>
a bug without NAT is to either incorrectly permit or incorrectly<br>
deny, depending on the bug. NAT is, therefore, a net gain, and<br>
a marginal improvement on the quality of the security provided<br>
by the solution.<br>
<br>
Now, I'm not emotionally attached to NAT, and I don't think its<br>
inevitable culling in an IPv6 world represents a huge problem. But<br>
I think you're making a mistake by suggesting that taking away<br>
NAT makes no difference because protecting the network is the firewall's<br>
job. We don't live in an ideal world, and some CPE firmware is so<br>
badly tested that it won't even boot, so I don't think you can trust<br>
the firewall. So what does that leave you with?<br>
<br>
<br>
</span><span style='color:black'><o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>I would not allow my</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>appliances to be
publically accessible but I'm fine with them being</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</blockquote>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'>publically addressable.</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'><br>
What about when your firewall is buggy? Is it ok then?<br>
<br>
<br>
- mark<br>
<br>
--<br>
Mark Newton
Email:<br>
<a href="mailto:newton@internode.com.au">newton@internode.com.au</a><span
class=apple-converted-space> </span><br>
(W)<br>
Network Engineer
Email:
<br>
<a href="mailto:newton@atdot.dotat.org">newton@atdot.dotat.org</a><span
class=apple-converted-space> </span> (H)<br>
Internode Systems Pty Ltd
Desk:
+61-8-82282999<br>
"Network Man" - Anagram of "Mark Newton" Mobile:
+61-416-202-223<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@ausnog.net">AusNOG@ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@ausnog.net">AusNOG@ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a></span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<p class=MsoNormal><span lang=EN-US style='font-size:7.0pt;font-family:"Helvetica","sans-serif";
color:black'>-- <br>
Matthew Moyle-Croft Internode/Agile Peering and Core Networks<br>
Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia<br>
Email:<span class=apple-converted-space> </span><a
href="mailto:mmc@internode.com.au">mmc@internode.com.au</a><span
class=apple-converted-space> </span> Web: <a
href="http://www.on.net/">http://www.on.net</a><br>
Direct: +61-8-8228-2909<span class=apple-tab-span> </span><span
class=apple-converted-space> </span> Mobile:
+61-419-900-366<br>
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
<div>
<p class=MsoNormal><span lang=EN-US style='color:black'> </span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif";
color:black'>-- <br>
Matthew Moyle-Croft Internode/Agile Peering and Core Networks<br>
Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia<br>
Email:<span class=apple-converted-space> </span><a
href="mailto:mmc@internode.com.au">mmc@internode.com.au</a><span
class=apple-converted-space> </span> Web: <a
href="http://www.on.net/">http://www.on.net</a><br>
Direct: +61-8-8228-2909<span class=apple-tab-span> </span><span
class=apple-converted-space> </span> Mobile:
+61-419-900-366<br>
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909</span><span
style='color:black'><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<div>
<p class=MsoNormal><span style='color:black'> <o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<div>
<div>
<p class=MsoNormal><span style='font-size:9.0pt;font-family:"Helvetica","sans-serif";
color:black'>-- <br>
Matthew Moyle-Croft Internode/Agile Peering and Core Networks<br>
Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia<br>
Email: <a href="mailto:mmc@internode.com.au">mmc@internode.com.au</a>
Web: <a href="http://www.on.net/">http://www.on.net</a><br>
Direct: +61-8-8228-2909<span class=apple-tab-span> </span>
Mobile: +61-419-900-366<br>
Reception: +61-8-8228-2999 Fax: +61-8-8235-6909<o:p></o:p></span></p>
</div>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>